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Executive  Summary 


Atlas  1.1:  The  Theory  of  Effective  Systems  Engineers,  describes  the  common  roles,  positions, 
patterns,  skills,  and  characteristics  of  systems  engineers,  the  common  values  they  provide,  and 
the  organizational  context  that  could  support  or  inhibit  their  effectiveness. 

Whenever  Atlas  is  presented,  there  are  many  questions  about  how  to  take  the  theory  and  apply 
it  in  practice.  As  the  Helix  team  has  continued  to  collect  data  and  has  worked  with  and  received 
feedback  from  organizations  that  are  using  and  reviewing  Atlas  as  a  mechanism  to  improve 
their  systems  engineering  workforce  development,  the  team  has  captured  approaches  that  may 
facilitate  and  potential  pitfalls  that  may  inhibit  these  improvements.  This  document  provides 
attributed  examples  from  the  organizations  that  have  publicly  shared  insights  on  their  use  of 
Atlas,  as  well  as  other  lessons  learned  the  team  has  gathered  over  the  five  years  of  the  project. 

This  document  contains: 

•  An  overview  of  Atlas  1.1,  for  reference 

•  Examples  of  organizations  which  have  utilized  Atlas 

•  Detailed  guidance  for  individuals  to  help  them  use  Atlas  and 

•  Detailed  guidance  for  organizations  to  support  their  use  of  Atlas. 

Individuals  can  use  this  guide  to  understand  and  assess  their  own  knowledge,  skills,  and 
abilities;  understand  and  analyze  their  own  career  paths;  and  link  the  two  to  develop  plans  and 
paths  for  growth.  Organizations  will  be  able  to  clear  and  consistent  definitions  for  systems 
engineering  and  the  value  that  systems  engineer  provide;  clear  and  consistent  expectations  on 
the  roles  systems  engineers  play  within  the  organization;  clear  and  consistent  expectations  on 
the  knowledge,  skills,  abilities,  behaviors,  and  cognitions  of  systems  engineers;  and  career  path 
recommendations  and  supporting  initiatives  that  enable  the  growth  and  development  of  the 
systems  engineering  workforce. 

By  using  Atlas,  the  Helix  team  believes  that  organizations  can  better  provide  their  systems 
engineers  with  the  information  and  tools  needed  to  grow  and  develop  into  an  effective 
workforce.  With  this  information,  the  Helix  team  believes  that  any  individual  or  organization 
can  implement  Atlas  as  appropriated  for  themselves  and  without  specific  support  from  the 
team.  However,  if  you  have  additional  questions  on  implementation  or  if  you  would  like 
assistance  on  implementing  Atlas  in  your  organization,  please  contact  the  Helix  team  at 
helix@stevens.edu. 
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1  Introduction  and  Purpose 


In  December  2016,  the  Helix  team  released  "Atlas  1.0:  The  Theory  of  Effective  Systems 
Engineers."  It  described  the  common  roles,  positions,  patterns,  skills,  and  characteristics  of 
systems  engineers,  the  common  values  they  provide,  and  the  organizational  context  that  could 
support  or  inhibit  their  effectiveness.  This  has  been  updated  through  the  Team's  work  in  2017, 
and  Atlas  1.1  (SERC-2018-TR-101-A)  was  released  concurrently  with  this  document.  (2018) 

Whenever  Atlas  is  presented,  there  are  many  questions  about  how  to  take  the  theory  and  apply 
it  in  practice.  As  the  Helix  team  has  continued  to  collect  data  and  has  worked  with  and  received 
feedback  from  organizations  that  are  using  and  reviewing  Atlas  as  a  mechanism  to  improve 
their  systems  engineering  workforce  development,  the  team  has  captured  approaches  that  may 
facilitate  and  potential  pitfalls  that  may  inhibit  these  improvements.  This  document  provides 
attributed  examples  from  the  organizations  that  have  publicly  shared  insights  on  their  use  of 
Atlas,  as  well  as  other  lessons  learned  the  team  has  gathered  over  the  five  years  of  the  project. 
Note  that  in  Helix,  the  team  has  strict  protocols  in  place  to  protect  the  anonymity  of 
participating  organizations  and  individuals;  this  is  why  only  organizations  that  have  publicly 
shared  their  stories  are  named  here. 

This  document  is  one  of  a  suite  which  were  published  simultaneously  reflecting  the  team's 
work  in  2017: 

•  Atlas  1.1  -  This  is  an  incremental  evolution  of  Atlas  that  reflects  feedback  from  the 
community,  additional  analysis,  and  maturation  of  the  team's  thinking  in  2017.  (SERC- 
2018-TR-101-A) 

•  Atlas  Career  Path  Guidebook  -  This  document  provides  analyses  of  the  Helix  dataset, 
providing  common  patterns  in  systems  engineers'  careers.  The  Guidebook  also  provides 
some  insights  on  questions  commonly  asked  of  the  Helix  team  around  career  paths  and 
the  team's  responses.  Finally,  additional  work  on  linking  proficiencies  to  career  paths 
has  been  completed  and  is  reflected  in  the  guide.  (SERC-2018-TR-101-C) 

•  2017  Helix  Technical  Report  -  This  document  provides  an  overview  of  the  work 
completed  in  2017  along  with  the  team's  vision  and  planning  for  future  Helix  work.  It 
references,  rather  than  repeats,  the  findings  of  the  other  documents.  In  addition,  it 
captures  the  detailed  methodologies  utilized  on  the  Helix  project.  (SERC-2018-TR-101) 

The  relationships  between  these  documents  are  illustrated  in  Figure  1,  below. 
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Figure  1.  Relationship  between  Helix,  Atlas,  and  Additional  Documents 


1.1  Users  and  Use  Cases 

There  are  two  primary  ways  in  which  Atlas  can  be  used  -  to  provide  insight  and  guidance  to 
individuals  and  to  inform  organizational-level  efforts.  Guidance  on  how  to  use  various  aspects 
of  Atlas  is  provided  throughout  the  various  sections  of  this  document.  This  section  pulls  this 
together,  describing  at  a  high  level  the  major  expected  uses  for  Atlas.  Several  organizations 
have,  to  varying  degrees,  tried  all  of  them.  Figure  2  shows  individual  uses. 
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Figure  2.  Expected  Uses  for  an  Individual  User 
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As  shown  in  Figure  2,  with  the  help  of  this  Guide  an  individual  is  expected  to  be  able  to: 


1.  Use  Proficiency  Self-Assessment  to  identify  current  proficiency  levels  as  well  as  past 
trends.  Proficiency  profiles  are  most  effective  when  they  are  examined  over  time.  An 
individual  will  benefit  from  understanding  these  patterns  and  using  them  to  inform 
potential  targets  for  the  future. 

2.  Use  Career  Path  self-assessment  to  categorize  and  analyze  past  forces  (experiences, 
mentoring,  and  education  and  training).  This  data  can  be  used  to  identify  any  clear  gaps 
in  Forces  over  time. 

3.  Use  Proficiency  and  Career  Path  self-assessments  to  identify  a  way  ahead  for  a  career. 

o  Identify  a  target  state.  Proficiency  profiles  provide  a  useful  starting  point  for 
discussions  with  the  organization  about  potential  future  positions  -  what 
positions  make  sense,  what  the  proficiency  expectation  for  this  position  are,  etc. 
These  future  goals  could  be  based  on  known  positions  within  an  organization 
(e.g.  "I  want  to  be  a  systems  architect")  or  individual  desire  (e.g.  "I  am  interested 
in  this  type  of  system").  Target  states  can  often  be  clarified  in  discussion  with  a 
mentor  or  leader  who  understands  the  expectations  for  different  types  of 
positions  in  the  organization  as  well  as  the  individual's  proficiencies. 

o  Assess  gaps  between  current  and  target  proficiency.  As  illustrated  in  Section 
5.8.1.,  once  target  proficiencies  have  been  identified,  they  can  be  plotted  in  a 
proficiency  profile  along  with  current  proficiency  levels.  This  provides  an  easy 
way  to  visualize  gaps  between  current  and  target  proficiency,  helping  an 
individual  understand  where  they  need  to  focus  their  growth. 

o  Pair  proficiency  gaps  with  career  path  information  to  identify  potential  ways  to 
improve  proficiency.  Experiences,  mentoring,  education,  or  training  are  all  ways 
that  proficiencies  can  be  improved  and  often  a  combination  of  forces  is  required 
to  reach  a  target  proficiency.  For  example,  a  gap  in  systems  engineering 
discipline  may  initially  be  addressed  by  targeted  training  or  education  programs. 
Flowever,  a  best  practice  identified  by  Helix  is  that  this  must  be  applied  on  the 
job  immediately  in  order  for  any  improvements  in  proficiency  to  become 
permanent.  If  a  mentor  can  help  guide  the  application  of  new  learning  in  these 
experiences,  there  is  likely  to  be  additional  improvement  in  proficiency  as  well. 
All  of  these  considerations  provide  a  starting  point  for  planning  and  can  be  used 
to  discuss  possibilities  with  management  or  leadership. 

Figure  3  shows  expected  organizational  uses  of  Atlas. 
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Figure  3.  Expected  Uses  for  Organizations 
As  shown  in  Figure  3,  an  organization  is  expected  to  be  able  to: 

*  Treat  the  workforce  as  a  collection  of  individuals.  Each  individual  can  gain  insight  on 
current  and  potential  target  capabilities  as  discussed  above.  By  taking  the  proficiency 
profiles  -  current  and  target  -  for  a  group  of  individuals,  the  organization  can  gain 
insight  into  any  current  capability  gaps  and  understand  desired  future  capabilities.  For 
example,  if  no  one  in  the  group  has  higher  than  a  proficiency  level  "6"  in  Technical 
Leadership,  but  the  organization  feels  it  needs  several  individuals  with  a  level  "8" 
proficiency  or  higher,  then  the  organization  has  identified  a  critical  skills  gap.  Paired  with 
the  target  states,  the  organization  can  then  identified  individuals  who  are  already 
interested  in  developing  their  Technical  Leadership  skills  and  can  focus  opportunities 
related  to  technical  leadership  on  these  individuals.  Likewise,  the  organization  may 
identify  individuals  who  are  believed  to  be  "high  potential"  for  technical  leadership  who 
may  not  have  identified  this  in  themselves  and  enable  a  conversation  about  future 
directions. 

The  Helix  team  recognizes  that  there  is  likely  to  be  some  systemic  changes  from  viewing  the 
workforce  holistically,  rather  than  as  a  collection  of  individuals  -  "the  whole  is  greater  than  the 
sum  of  its  parts"  -  but  the  research  to  date  has  not  enabled  the  team  to  understand  this. 
Future  research  will  include  modeling  to  support  holistic  workforce-level  analysis. 
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*  Use  the  career  path  data  from  individuals  to  identify  patterns  of  the  overall 
workforce.  Similar  to  the  point  above,  organizations  can  use  the  career  path  data  for 
the  individuals  in  the  workforce  to  identify  overall  patterns.  For  example,  perhaps  less 
than  5%  of  the  workforce  has  experience  in  the  role  of  "Concept  Creator".  If  the 
organization  has  identified  this  as  a  critical  area  for  growth  of  systems  engineers,  this 
may  indicate  that  the  organization  should  develop  initiatives  to  foster  growth  in  this 
area.  Likewise,  if  there  is  an  area  of  the  lifecycle  that  is  commonly  missed  in  the 
workforce,  the  organization  can  determine  if  this  is  a  critical  gap  or  whether  it  makes 
sense  in  the  organizational  context.  For  example,  if  only  10%  of  the  workforce  has 
experiences  in  "Systems  Deployment  and  Use",  but  the  organization  does  not 
participate  in  operation  and  maintenance  of  its  systems,  then  this  may  be  seen  as 
acceptable.  The  organization  also  now  has  data  about  the  workforce  that  it  can  use  to 
fill  gaps.  For  example,  if  the  organization  needed  perspective  on  a  project  specific  to 
"Systems  Deployment  and  Use",  the  data  will  provide  insight  on  who  in  the  organization 
has  this  experience. 

*  Use  workforce  data  to  improve  or  create  new  organizational  development  initiatives. 

Using  the  gap  analysis  across  current  and  future  desired  capabilities,  the  organization 
can  identify  opportunities  or  set  strategic  goals  regarding  workforce  capability.  As 
illustrated  in  the  examples  above,  this  information  would  then  provide  opportunities  for 
improved  or  new  development  initiatives. 


1.2  About  This  Document 

This  document  was  developed  with  these  two  user  stories  in  mind,  which  is  reflected  in  the 
structure  below.  In  addition,  the  team  believes  that  sharing  examples  of  organizations  that 
have  utilized  Atlas  is  important;  some  of  these  stories  are  collected  together  and  others  are 
woven  throughout.  The  major  sections  of  this  document  include: 

•  2:  Atlas  1.1  Overview:  While  the  details  of  1.1  can  be  found  in  a  separate  document, 
this  section  provides  an  overview  of  the  theory.  This  provides  critical  context  to 
understand  the  recommendations  provided  through  this  document.  Where  additional 
detail  about  the  model  is  required  to  elucidate  recommendations,  the  detail  is  provided 
within  the  text  of  the  other  sections. 

•  3:  Atlas  in  Use:  This  section  provides  insights  and  user  stories  from  organizations  that 
have  publicly  participated  presented  this  information. 

•  4:  Using  Atlas  1.1  for  Individuals:  This  section  provides  guidance  for  individuals  who 
wish  to  use  Atlas  for  their  own  personal  growth  and  development.  It  incorporates 
feedback  received  by  the  Helix  team  from  individuals  who  have  participated  in  Helix  or 
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who  reached  out  to  the  team  to  share  their  questions  and  experiences;  no  individuals 
are  named. 

•  5:  Using  Atlas  1.1  for  Organizations:  This  section  provides  guidance  for  organizations 
who  wish  to  use  Atlas  to  help  guide  and  grow  their  systems  engineers.  It  includes 
examples  from  the  organizations  highlighted  in  Section  3  by  name.  There  are  additional 
examples  organizations  which  have  participated  and  provided  feedback  on  their 
experiences  but  not  spoken  publicly;  these  are  anonymous. 

•  6:  Conclusions:  This  section  provides  a  brief  overview  and  example  of  what  it  could  look 
like  for  an  organization  to  implement  Atlas. 

Paper-based  tools,  references,  and  additional  guidance  are  contained  in  the  appendices.  The 
Excel-based  tool  and  the  guide  for  use  can  be  found  at  www.sercuarc.org/projects/helix. 
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2  Atlas  1.1  Overview 


Atlas  is  a  set  of  general  principles  and  ideas  that  relates  to  the  subject  of  what  makes  systems 
engineers  effective  and  why.  In  doing  so,  Atlas  also  provides  insights  into  how  individuals  can 
develop  into  effective  systems  engineers  throughout  their  careers  and  what  organizations  can 
do  to  support  this  development. 


2.1  Atlas  Overview 


The  overview  of  Atlas  in  the  context  of  an  individual  systems  engineer  employed  in  an 
organization  is  captured  in  the  systemigram  illustrated  in  Figure  4.  A  systemigram  consists  of 
nodes  that  contain  noun  phrases,  links  that  contain  verb  phrases,  and  is  to  be  read  as  sentences 
along  the  direction  of  the  arrows.  The  primary  sentence  is  read  from  the  top  left  node  to  the 
bottom  right  node  and  presents  the  main  theme  of  the  systemigram.  In  the  ensuing 
discussions,  sentences  to  be  read  in  the  systemigram  are  italicized,  where  nodes  are 
represented  in  square  brackets. 
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Figure  4.  Atlas  1.1 
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From  Figure  4  above,  it  can  be  seen  that  the  main  theme  of  Atlas  is:  '[Individual  Systems 
Engineer]  who  provides  [Consistent  Delivery]  of  [Value]  is  an  [Effective  Systems  Engineer]’.  This 
fundamental  definition  of  an  effective  systems  engineer  hinges  on  [Value],  and  it  can  be  seen 
that  '[Organization]  defines  [Value]'.  Therefore,  it  is  on  the  organization  to  define  the  value 
that  the  systems  engineer  is  expected  to  provide.  Further,  the  individual  systems  engineer 
provides  '[Value]  by  performing  in  [Positions  and  Roles]  assigned  by  [Organization]' .  Therefore, 
it  is  again  on  the  organization  to  establish  the  position  of  the  systems  engineer  in  terms  of  roles 
and  responsibilities,  keeping  in  mind  that  '[Positions  and  Roles]  require  a  specific  level  of 
[Proficiency]  that  enables  [Consistent  Delivery]  of  [Value]’. 

The  core  of  Atlas  is  the  proficiency  of  the  individual  systems  engineer  -  what  proficiency 
means,  and  how  it  can  be  improved.  '[ Individual  Systems  Engineer]  has  [Personal  Development 
Initiatives]'  and  '[Organization]  has  [Organizational  Development  Initiatives]';  together,  they 
'generate  [Forces]  that  impact  [Proficiency]' .  At  the  same  time,  '[Individual  Systems  Engineer] 
has  [Personal  Characteristics]  that  influence  the  impact  of  [Forces]'  and  '[Organization]  has 
[Organizational  Characteristics]  that  influence  the  impact  of  [Forces]'  -these  forces  may  have  a 
positive  or  a  negative  influence.  Further,  both  personal  enabling  characteristics  and 
organizational  characteristics  'impact  [Consistent  Delivery]  of  [Value]';  again,  the  impact  can  be 
positive  or  negative.  Amidst  all  these  influences  and  impacts,  the  challenge  for  the  individual 
systems  engineer  and  the  organization  is  to  improve  the  '[Proficiency]  that  enables  [Consistent 
Delivery]  of  [Value]’  to  the  organization. 


2.2  Dynamic  Aspect  of  Atlas 

The  Atlas  overview  illustrated  in  Figure  4  can  be  considered  as  a  quasi-static  snapshot  in  time, 
but  many  of  the  elements  of  Atlas  are  dynamic  in  nature.  The  level  of  proficiency  of  an 
individual  systems  engineer  is  not  fixed,  but  is  constantly  changing  due  to  the  impact  of  forces 
over  time.  Similarly,  other  elements  of  Atlas,  including  characteristics  and  initiatives  of  the 
individual  systems  engineer  and  of  the  organization,  continue  to  change  over  time.  Further,  as 
the  level  of  proficiency  of  an  individual  systems  engineer  increases  over  time,  the  organization 
is  likely  to  place  that  systems  engineer  into  different  positions. 

This  dynamic  aspect  of  Atlas  is  not  captured  in  the  overview,  but  is  reflected  in  the  career  paths 
of  individuals  over  time,  where  an  individual's  career  path  is  the  precise  combination  of  the 
forces  they  undergo  in  the  positions  and  roles  they  perform  in  over  their  entire  career. 

Leading  up  to  the  publication  of  Atlas  1.0,  the  Helix  team  defined  methods  to  depict  and 
analyze  the  career  paths  of  systems  engineers  and  used  those  methods  to  analyze  the  systems 
engineers  in  its  interview  sample,  and  how  those  systems  engineers  are  shaped  by  the  impact 
of  forces  and  positions  and  roles  over  time.  This  is  notionally  represented  in  Figure  5. 
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Figure  5.  Career  Path:  A  Dynamic  View  of  Atlas 

The  Helix  team  has  defined  methods  to  depict  and  analyze  the  career  paths  of  systems 
engineers.  The  team  used  those  methods  to  analyze  the  systems  engineers  in  its  interview 
sample  and  to  understand  how  those  systems  engineers  are  shaped  by  the  impact  of  forces  and 
positions  &  roles  overtime.  These  are  reflected  in  the  companion  Career  Path  Guidebook. 
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3:  Examples  of  Atlas  in  Use 


Over  the  last  several  years,  many  organizations  have  shared  their  experiences  in  using  Atlas 
with  the  Helix  team.  Since  some  organizations  have  spoken  publicly  about  their  participation 
and  implementation,  it  allows  the  team  to  also  openly  acknowledge  their  involvement  and 
findings.  Otherwise,  under  strict  IRB  protocol  and  to  also  allow  the  greatest  openness  within 
the  interviews,  the  team  prohibits  mention  of  participating  organizations.  Below  are  five 
summarized  examples  of  Atlas  in  practice  by  alphabetical  order  of  the  organizations.  Additional 
details  from  these  organizations,  including  slides  presented  publicly,  are  available  in  the  Helix 
Workshop  reports,  which  can  be  found  at  http://www.sercuarc.org/projects/helix/ 


3.1ARDEC 

The  Systems  Engineering  Directorate  (SED)  in  the  Army  Research,  Development,  and 
Engineering  Center  (ARDEC)  became  involved  with  Helix  in  2014.  Mr.  Albert  Stanbury  had  been 
interested  in  the  INCOSE  competency  framework  and  saw  the  SERC  as  another  organization 
addressing  the  challenges  in  workforce  development. 

ARDEC  SED  publicly  stated  in  Helix  workshops  that  they  participated  in  Helix  interviews,  and  the 
participants  ranged  from  junior  to  senior  with  about  half  participating  in  follow-  up  interviews. 
Their  interview  data  was  aggregated  into  the  older  Atlas  model,  which  was  published  in 
November  2014.  ARDEC  SED  was  interested  in  understanding  their  population  individually  as  it 
related  to  the  general  Helix  interview  data.  A  report  was  delivered  by  Helix  in  March  2015, 
which  confirmed  some  of  the  things  emphasized  in  workforce  development  at  SED  and 
additionally  identified  areas  that  need  further  improvement. 

When  the  SED  was  created  approximately  10  years  ago,  it  had  to  first  define  systems 
engineering.  Policies  created  tie  to  DoD  policies  for  uniformity,  and  basic  courses  in  systems 
engineering  that  were  developed  are  being  taught  at  ARDEC.  Engineers  encompassing  a  variety 
of  experiences  were  brought  into  the  department.  In  conjunction  with  Stevens  Institute  of 
Technology,  they  developed  the  systems  engineering  courses.  These  courses  cover  topics 
across  the  systems  engineering  spectrum;  some  courses  are  specific  to  competencies,  i.e., 
model-based  systems  engineering  (MBSE).  A  number  of  the  participants  have  obtained  a 
master's  degree  in  systems  engineering  as  a  result  of  their  involvement. 

The  new  hires  at  SED  are  put  through  classroom  and  on  the  job  training  with  a  senior  systems 
engineer.  The  organization-specific  mentoring  tactics  are  shadowing,  workshops,  lunch-and- 
learn,  and  training  courses  in  mentoring.  Mentors  volunteer  and  enjoy  training  junior  systems 
engineers  in  their  area  of  expertise. 

Several  parts  of  Atlas  are  very  relevant  to  the  SED,  and  Mr.  Stanbury  reported  they  are  being 
utilized  from  a  tactical  standpoint.  Since  its  usefulness  was  illustrated,  the  team  SED  to  pilot 
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certain  aspects  of  Atlas  implementation  in  September  2015,  where  classic  engineers  and 
managers  from  other  departments  were  also  interviewed.  The  goals  of  the  pilot  were  to: 

•  Identify  the  value  that  systems  engineering  provides  to  engineering  overall,  including 
other  departments'  perspective  of  this  value, 

•  Generate  an  understanding  of  the  proficiencies  required  of  key  positions  and  the 
proficiencies  of  systems  engineers  in  these  positions,  and 

•  Help  ARDEC  understand  how  to  apply  Atlas  independently. 

One  of  the  primary  activities  conducted  with  ARDEC  was  an  alignment  exercise  to  identify 
appropriate  profiles  for  standard  positions  using  the  Atlas  model.  This  included  working  with 
the  management  team  to  develop  standard  descriptions  for  these  positions  based  on  the  Atlas 
roles.  The  Helix  team  then  worked  with  management  team  to  develop  an  initial  "baseline" 
proficiency  profile  for  each  position,  conducted  proficiency  self-assessments  with  individuals  in 
those  positions,  then  compared  the  management  expectations  and  individual  assessments. 


3.2  BAE 

BAE  began  its  involvement  with  Helix  in  2012  under  the  direction  of  Mr.  Mark  Carlson.  The  BAE 
systems  engineering  group  is  a  geographically  diverse  organization  of  about  700  employees. 
The  BAE  organization  is  forward-leaning,  and  as  such,  the  workforce  has  a  broad  skill  range  and 
are  encouraged  to  continue  expanding  their  expertise  by  completing  coursework  and  lunch- 
and-learns.  The  workforce  is  also  provided  all  the  tools  required  for  systems  engineering,  and 
there  has  recently  been  a  major  push  towards  model-based  systems  engineering. 

When  he  joined  the  department  in  2012,  one  of  Mr.  Carlson's  first  observations  was  that  new 
graduates  were  struggling  with  basic  systems  engineering  principles.  Since  then,  employees 
with  less  than  10  years  of  experience  have  been  moved  back  to  the  organizational  area  related 
to  their  core  or  educational  background,  often  in  classic  engineering.  At  BAE,  there  is  a 
requirement  for  individuals  to  understand  their  core  professions  fully  before  broadening  to 
become  systems  engineers. 

BAE  now  manages  and  tracks  skills,  focusing  on  growing  people  internally  versus  hiring  in  new 
systems  engineers.  They  center  on  positions  that  have  critical  skills  -  such  as  chief  engineers  - 
and  grow  and  develop  the  necessary  competencies  internally.  Although  employees  are  aligned 
with  a  specific  track,  they  are  free  to  work  on  other  assignments;  e.g.,  there  are  SMEs  who 
focus  on  a  particular  technology  and  provide  support  that  is  different  to  that  of  systems 
engineering  within  the  organization. 

The  workforce  profile  is  bimodal  at  BAE,  with  primarily  junior  and  senior  systems  engineers, 
and  so  an  advisor  program  was  devised  to  grow  junior  systems  engineers  into  mid-level  systems 
engineers  more  rapidly.  Many  senior  systems  engineers  volunteered  to  be  advisors  and  career 
coaches  for  the  junior  employees.  They  provide  guidance  and  play  a  big  part  in  the  peer  review 
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board  (PRB)  process  that  provides  recommendations  on  nominations  into  systems  engineering 
positions.  This  has  had  a  positive  effect  on  individuals  because  of  its  transparency. 

Mr.  Carlson  explained  that  although  some  of  these  approaches  were  underway  before  the  Helix 
recommendations,  the  Helix  suggestions  aligned  and  provided  external  validation  for  the 
planned  changes. 


3.3  MITRE 

For  the  workshop  in  2017,  Dr.  Rob  Pitsko  and  Ms.  Laura  Ricci  from  MITRE  provided  a 
presentation  on  how  MITRE  responded  to  and  planned  to  utilize  the  findings  of  Atlas. 

To  provide  background,  MITRE  participated  in  Helix  interviews  during  2015,  and  has 
subsequently  held  a  series  of  Helix  review  meetings  in  2016,  initiating  a  pilot  of  Atlas.  During 
2016,  Dr.  Pitsko  and  Mrs.  Ricci  provided  insights  on  the  expected  approach  to  using  Atlas  at 
MITRE,  and  the  MITRE  and  Helix  team  members  discussed  potential  use  cases,  parsing  the 
contents  of  Atlas  to  discuss  areas  where  additional  tailoring  could  be  required.  Some  tailoring 
was  already  expected  -  particularly  to  the  proficiency  model  -  to  make  Atlas  more  suitable  to 
the  MITRE  organizational  context.  MITRE  used  the  proficiency  self-assessments  to  inform 
conversations  between  systems  engineers  and  their  managers  to  better  inform  career  planning. 
Dr.  Pitsko  and  Mrs.  Ricci  held  a  focus  group  with  MITRE  systems  engineers,  and  then  progressed 
to  a  pilot  used  in  the  fall.  The  goals  of  the  pilot  included: 

•  Gauging  the  effectiveness  of  proficiency  self-assessments  for  career 
planning/development, 

•  Understanding  how  Atlas  aligns  with  the  MITRE  systems  engineering  competency 
model,  which  is  also  to  be  updated,  and 

•  Providing  insight  back  to  the  Helix  team. 

These  discussions  were  deeply  helpful  to  the  Helix  team.  For  example,  dialogue  on  how  MITRE 
may  need  to  tailor  the  proficiency  model  to  align  with  their  organizational  context,  their 
existing  competency  model,  and  their  Systems  Engineering  in  the  Modern  Era  (SEME)  initiative 
helped  the  Helix  team  more  clearly  define  where  and  how  tailoring  is  expected  and  where  the 
proficiency  model  is  going  to  be  stable  for  future  organizations. 

After  the  goals  of  the  focus  group  were  realized,  MITRE  did  not  want  to  completely  change 
what  they  were  doing  to  apply  Atlas,  but  instead  to  see  how  some  elements,  particularly  the 
proficiency  framework,  could  be  used  to  improve  the  workforce  development  efforts  already 
occurring.  They  wanted  to  start  with  one  question:  Can  this  profile  help  us  to  have  a  consistent 
conversation? 
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In  2016,  MITRE  started  a  pilot  to  utilize  the  Atlas  proficiency  framework  as  a  means  to  enhance 
its  Clear  Conversations  -  the  process  by  which  employees  and  their  managers  review  progress 
and  construct  a  plan  for  career  development.  First,  the  management  and  senior  leadership  in 
the  Systems  Engineering  Technical  Center  at  MITRE  reviewed  the  framework  and  tailored  it  to 
be  more  specific  to  the  MITRE  context,  incorporating  areas  of  the  competency  model  MITRE 
already  had  including  adding  a  proficiency  area  for  SEME  (Systems  Engineering  in  the  Modern 
Era)  topics.  In  the  pilot,  a  select  group  of  individuals  were  asked  to  complete  a  tailored 
proficiency  profile  prior  to  their  Clear  Conversation  with  their  manager.  The  manager  then 
would  review  the  profile  to  give  clear  and  consistent  feedback  (a  common  technique  for  360° 
reviews).  Once  the  employee  and  manager  agreed  on  a  baseline,  they  could  then  map  out  a 
target  profile  -  areas  in  which  both  agreed  the  employee  should  work  on  growing  in  the  future 
-  and  a  path  for  that  development. 

MITRE  then  collected  feedback  on  how  well  the  use  of  the  proficiency  profiles  worked,  and 
whether  it  was  worthwhile  to  continue.  Based  on  the  feedback,  MITRE  is  expanding  the  pilot  to 
additional  employees. 


3.4  Rockwell  Collins 

There  was  a  historical  joint  effort  between  Rockwell  Collins  and  the  Stevens  Institute  of 
Technology  to  provide  systems  and  software  engineering  education  at  Rockwell  Collins,  at  the 
time  Rockwell  Collins  decided  to  participate  in  the  Helix  project.  The  systems  engineering 
department  has  been  comprised  of  a  mix  of  new-hires,  recent  graduates,  and  employees  from 
varying  departments  interested  in  systems  engineering.  It  was  noted  that  new  graduates  were 
generally  not  successful  as  systems  engineers.  Within  Rockwell  Collins,  aerospace  engineers 
seemed  to  make  the  transition  to  systems  engineering  best;  they  have  to  study  many  different 
aspects  of  engineering  to  understand  engineering  the  aircraft  as  a  whole  and  Rockwell  Collins 
believes  that  this  systems-level  perspective  may  be  what  facilitates  their  transition.  Mr.  Mark 
Gries,  mentioned  during  a  Helix  workshop  that  at  Rockwell  Collins  systems  engineers  are  well 
compensated  monetarily,  which  provides  additional  incentive  for  classic  engineers  to  move  into 
the  systems  engineering  department.  For  the  past  five  or  so  years,  there  has  been  a  concerted 
effort  to  improve  systems  engineering  at  Rockwell  Collins,  and  Atlas  seemed  like  a  useful  tool 
to  assist  in  the  effort.  Mr.  Gries  identified  several  aspects  of  Atlas  that  Rockwell  Collins  has 
found  to  be  useful: 

1.  There  is  a  notion  that  some  people  do  not  have  the  systems  engineering  mindset,  where 
some  aspect  of  big  picture  thinking  may  be  inherent.  Because  of  this,  not  all  good 
engineers  will  make  good  systems  engineers.  Training  is  not  enough  to  cultivate  this 
proficiency;  experiences  and  mentoring  are  also  required  as  well  as  personal  enabling 
characteristics.  Rockwell  Collins  finds  Atlas  very  helpful  in  explaining  how  this  critical 
skill  can  be  developed. 
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2.  Recognition  that  the  organization  plays  a  major  role.  There  are  certain  things  an 
organization  can  do  to  inhibit  systems  engineers  for  being  as  effective  as  they  could  be. 
At  Rockwell  Collins,  specifically,  there  is  no  centralized  systems  engineering  department; 
there  are  many  different  systems  engineering  organizations  throughout  other 
departments.  This  makes  it  difficult  to  have  consistency  in  delivery  mechanisms,  and  it  is 
difficult  to  engage  systems  engineers  from  multiple  departments  together  to  talk  about 
discipline. 

3.  The  comprehensive  Atlas  proficiency  model  provides  the  nuts  and  bolts  of  systems 
engineers'  core  skills,  and  Rockwell  Collins  believes  this  is  a  good  tool  to  put  in  front  of  a 
worker  to  discuss  his  or  her  profile  and  any  changes  needed  for  career  advancement. 
This  facilitates  a  better  discussion  between  the  manager  and  the  engineer  to  work 
together  and  forge  a  path  ahead. 

Rockwell  Collins  is  planning  to  use  Atlas  to  help  the  organization  move  from  a  generic 
performance  and  time-based  assessment  and  advancement  approach  to  a  more  competency- 
based  one.  Progression  and  advancement  have  historically  been  based  on  time  spent  in  the 
position  and  generic  annual  performance  reviews.  While  this  is  not  a  terrible  surrogate  for 
competency,  this  process  does  not  provide  satisfactory  feedback  for  the  employee. 
Competency-based  progression  requires  metrics  and  it  has  to  be  simple  enough  that  people  can 
understand  it.  Ideally,  it  would  also  help  to  develop  and  improve  training  content  to  recognize 
and  develop  what  it  means  to  have  skill  mastery  for  systems  engineers.  Rockwell  Collins 
believes  that  the  Helix  proficiency  model  is  a  very  good  resource  to  support  their  approach. 

The  ideal  Rockwell  Collins  system  engineer  is  built  in  many  ways,  from  experience  in  multiple 
roles  to  learning  the  domain.  It  takes  about  five  years  to  develop  expert  understanding  of  a 
domain,  and  their  leadership  believes  that  junior  systems  engineers  feel  this  is  too  a  long  time. 
The  leadership  perceives  that  if  junior  systems  engineers  were  provided  a  better  roadmap  for 
how  to  develop  themselves,  it  would  be  extraordinarily  helpful  and  would  represent  the 
benefits  of  focusing  in  a  specific  area  for  a  longer  period  of  time. 

Rockwell  Collins  likes  the  notion  of  being  able  to  sit  with  an  employee  and  give  them  a  set  of 
expectations  of  how  to  grow  across  their  careers.  This  is  not  relevant  only  to  the  systems 
engineers,  but  for  all  engineers.  They  believe  that  the  concepts  and  framework  of  Atlas  are 
transferrable,  though  the  details  will  change  and  be  tailored  for  classic  engineers. 


3.5  Rolls-Royce 

As  with  many  organizations  that  have  utilized  Atlas,  Atlas  was  not  the  initial  step  Rolls-Royce 
took  to  understand  or  improve  its  systems  engineering  workforce.  Rolls-Royce  had  an  existing 
competency  model  for  systems  engineering  prior  to  the  Helix  work.  However,  Atlas  provided  a 
useful  point  of  comparison;  Rolls-Royce  compared  the  Atlas  proficiency  model  and  the  Rolls- 
Royce  competency  model  to  see  if  there  were  any  gaps  or  adjustments  needed.  Likewise,  the 
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Helix  roles  provided  a  useful  point  of  comparison  between  the  Atlas  systems  engineering  roles 
and  the  specific  roles  defined  in  the  organization. 

Rolls-Royce's  end  objective  is  that  at  some  point  systems  engineering  practices  get  embedded 
into  their  practices  and  internalized  to  the  extent  that  they  do  not  have  to  talk  about  "systems 
engineering."  As  stated  by  Mr.  Richard  Beasley  at  the  4th  Helix  Workshop,  "The  goal  is  not  to 
talk  about  systems  engineering,  it's  that  that's  just  the  way  we  work."  Comparing  their 
competency  model  with  that  of  Atlas  helped  guide  approaches  to  address  normalizing  systems 
engineering  methodologies  throughout  workforce. 

One  of  the  areas  of  note  from  this  work  is  that  every  engineer  should  have  soft  skills  so  people 
can  holistically  understand  the  status  of  development  efforts,  to  which  Rolls-Royce  was  pleased 
to  see  the  further  breakdown  of  the  proficiencies  discussed  in  Atlas.  The  core  competencies 
every  engineer  must  have  at  Rolls-Royce  include: 

•  Technical  Communications 

•  Planning/Project/Program  Mining 

•  Systems  Thinking 

•  Curiosity 

These  align  with  several  of  the  skills  and  personal  characteristics  of  Atlas.  In  addition  to  the  core 
competencies,  Rolls-Royce  has  between  six  and  ten  competencies  for  each  "role."  (Beasley, 
2012)  (Note:  in  Rolls-Royce,  "role"  denotes  a  specific  job,  which  would  be  a  "position"  in  Atlas.) 
In  addition,  there  are  four  levels  of  expertise  in  the  organization  (Aware,  Supervised 
Practitioner,  Practitioner,  Expert)  and  they  are  considering  creating  a  fifth  level  between 
"Practitioner"  and  "Expert"  to  indicate  senior  practitioners.  This  aligns  with  the  updated  five- 
level  proficiency  rubric  in  Atlas  1.1. 
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4:  Using  Atlas  1.1  for  Individuals 


This  section  contains  general  guidance  on  using  Atlas  for  self-assessment  and  planning  for 
individuals  to  guide  their  own  self-assessments  and  growth. 


4.1  Proficiency 

One  of  the  aspects  of  Atlas  that  has  resonated  greatly  with  individuals  is  the  proficiency  model. 
It  provides  insight  into  the  knowledge,  skills,  abilities,  behaviors,  and  cognitions  required  for 
systems  engineers  to  be  effective. 


4.1.1  Atlas  Proficiency  Model 

The  Atlas  proficiency  model  consists  of  six  proficiency  areas  based  on  the  Helix  interview  data, 
as  shown  in  Figure  6  below. 


Math  /  Science  / 
General  Engineering 


System's  Domain  & 
Operational  Context 


Systems  Engineering 
Discipline 


Systems  Engineering 
Mindset 


Figure  6.  Proficiency  Areas  for  Systems  Engineers 


1.  Math/Science/General  Engineering:  Foundational  concepts  from  mathematics, 
physical  sciences,  and  general  engineering; 

2.  System's  Domain  &  Operational  Context:  Relevant  domains,  disciplines,  and 
technologies  for  a  given  system  and  its  operation; 

3.  Systems  Engineering  Discipline:  Foundation  of  systems  science  and  systems 
engineering  knowledge; 

4.  Systems  Engineering  Mindset:  Skills,  behaviors,  and  cognition  associated  with  being  a 
systems  engineer; 

5.  Interpersonal  Skills:  Skills  and  behaviors  associated  with  the  ability  to  work  effectively 
in  a  team  environment  and  to  coordinate  across  the  problem  domain  and  solution 
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domain;  and 


6.  Technical  Leadership:  Skills  and  behaviors  associated  with  the  ability  to  guide  a  diverse 
team  of  experts  toward  a  specific  technical  goal. 

Proficiency  areas  1  to  3  consist  of  primarily  technically  based  skills,  while  proficiency  areas  4  to 
6  consist  primarily  of  the  interdisciplinary  skills.  The  six  proficiency  areas  in  Atlas  are  further 
divided  into  categories  and,  in  some  cases,  into  topics,  as  shown  in  Table  1. 


Table  1.  Atlas  Proficiency  Areas,  Categories,  and  Topics 


Area 

Category 

Topic 

1.  Math  /  Science  / 
General 

Engineering 

1.1.  Natural  Science  Foundations 

1.2.  Engineering  Fundamentals 

1.3.  Probability  and  Statistics 

1.4.  Calculus  and  Analytical  Geometry 

1.5.  Computing  Fundamentals 

2.  Systems'  Domain  & 
Operational 

Context 

2.1.  Principal  and  Relevant  Systems 

<  List  of  Principal  and  Relevant  Systems  > 

2.2.  Familiarity  with  Principal  System's 
Concept  of  Operations  (ConOps) 

2.3.  Relevant  Domains 

<  List  of  relevant  Domains  > 

2.4.  Relevant  Technologies 

<  List  of  relevant  Technologies  > 

2.5.  Relevant  Disciplines  and  Specialties 

<  List  of  relevant  Disciplines  and 

Specialties  > 

2.6.  System  Characteristics 

<  List  of  applicable  System  Types,  Scales, 
and  Levels  > 

3.  Systems 

Engineering 

Discipline 

3.1.  Lifecycle 

3.1.1  Lifecycle  Models 

3.1.2  Concept  Definition 

3.1.3  System  Definition 

3.1.4  System  Realization 

3.1.5  System  Deployment  and  Use 

3.1.6  Product  and  Service  Life 

Management 

3.2.  Systems  Engineering  Management 

3.2.1  Planning 

3.2.2  Risk  Management 

3.2.3  Configuration  Management 

3.2.4  Assessment  and  Control 

3.2.5  Quality  Management 

3.3.  SE  Methods,  Processes,  and  Tools 

3.3.1  Balance  and  Optimization 

3.3.2  Modeling  and  Simulation 

3.3.3  Development  Process 

3.3.4  Systems  Engineering  Tools 

3.4.  Systems  Engineering  Trends 

3.4.1  Complexity 

3.4.2  Model  Oriented  Systems  Engineering 

3.4.3  Systems  Engineering  Analytics 

3.4.4  Agile  Systems  Engineering 
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Area 


Category 


Topic 


4.  Systems 

Engineering 

Mindset 

4.1.  Big-Picture  Thinking 

4.2.  Paradoxical  Mindset 

4.2.1  Big-Picture  Thinking  and  Attention  to 
Detail 

4.2.2  Strategic  and  Tactical 

4.2.3  Analytic  and  Synthetic 

4.2.4  Courageous  and  Humble 

4.2.5  Methodical  and  Creative 

4.3.  Adaptability 

4.4.  Abstraction 

4.5.  Foresight  and  Vision 

5.  Interpersonal  Skills 

5.1.  Communication 

5.1.1  Audience 

5.1.2  Content 

5.1.3  Mode 

5.2.  Listening  and  Comprehension 

5.3.  Working  in  a  Team 

5.4.  Influence,  Persuasion  and  Negotiation 

5.5.  Building  a  Social  Network 

6.  Technical 

Leadership 

6.1.  Building  and  Orchestrating  a  Diverse 
Team 

6.2.  Balanced  Decision  Making  &  Rational 
Risk  Taking 

6.3.  Guiding  Diverse  Stakeholders 

6.4.  Conflict  Resolution  &  Barrier  Breaking 

6.5.  Business  and  Project  Management 

Skills 

6.6.  Establishing  Technical  Strategies 

6.7.  Enabling  Broad  Portfolio-Level 
Outcomes 

For  additional  detail  on  the  proficiency  model,  please  see  Atlas  1.1.  (2018,  SERC-2018-TR-101- 

A) 
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4.1.2  Assessing  Proficiency 


One  area  that  has  proven  more  difficult  than  expected  for  the  Helix  team  is  the  development  of 
a  rubric  to  guide  assessment  of  proficiencies.  The  team  has  helped  over  100  individuals  conduct 
self-assessments  and  had  exploratory  conversation  around  these  assessments,  but  the  primary 
roadblock  to  this  has  been  that  individuals  struggle  to  explain  skills  versus  how  they  attained 
them. 

For  example,  if  an  individual  said  that  they  were  a  6  out  of  10  for  "Systems  Engineering 
Discipline",  the  team  would  ask  what  that  "6"  really  meant.  The  answers  would  often  be 
something  like  this:  Well,  I've  been  doing  systems  engineering  for  5  years  and  I've  seen  most  of 
the  lifecycle  and  I  am  good  with  the  tools  we  utilize  here.  Note  that  "I've  seen  most  of  the 
lifecycle"  -  an  aspect  of  their  career  path  -  is  different  from  "I  am  able  to  provide  clear  value 
and  leadership  at  any  stage  of  the  lifecycle."  When  the  team  probed  further,  individuals  simply 
did  not  have  the  vocabulary  to  describe  precisely  the  differences  between  a  "5  out  of  10"  and  a 
"7  out  of  10". 

In  their  work  to  be  published  in  2018,  Pyster,  Hutchison,  and  Henry  tackled  this  in  a  different 
way.  They  identified  a  comparable  proficiency  scale  -  utilizing  broad  descriptions  for  general 
levels  of  proficiency  -  rather  than  trying  to  tailor  a  specific  definition  for  every  single  topic. 
Their  rubric  is  adapted  from  a  rubric  developed  by  the  National  Institutes  of  Health  (NIH).  The 
"NIH  Proficiency  Scale  is  an  instrument  used  to  measure  one's  ability  to  demonstrate  a 
competency  on  the  job."  The  rubric  includes  five  proficiency  levels,  titled  'Fundamental 
Awareness'  to  "Expert'."  Pyster  et  al.  have  adapted  this  to  apply  to  the  Atlas  framework,  as 
illustrated  in  Table  2.  (2018,  in  print) 


Table  2.  Proficiency  Levels  (adapted  from  Pyster  et  al.  2018,  in  print,  used  with  permission) 


# 

Level 

Level  Description 

1 

Fundamental 

Awareness 

Individual  has  common  knowledge  or  an  understanding  of  basic  techniques  and 
concepts.  Focus  is  on  learning  rather  than  doing. 

2 

Novice 

Individual  has  the  level  of  experience  gained  in  a  classroom  or  as  a  trainee  on-the-job. 
Individual  can  discuss  terminology,  concepts,  principles,  and  issues  related  to  this 
proficiency,  and  use  the  full  range  of  reference  and  resource  materials  in  this 
proficiency.  Individual  routinely  need  help  performing  tasks  that  rely  on  this  proficiency. 

3 

Intermediate 

Individual  can  successfully  complete  tasks  relying  on  this  proficiency.  Help  from  an 
expert  may  be  required  from  time  to  time,  but  the  task  is  usually  performed 
independently.  The  individual  has  applied  this  proficiency  to  situations  occasionally 
while  needing  minimal  guidance  to  perform  it  successfully.  Individual  understands  and 
can  discuss  the  application  and  implications  of  changes  in  tasks  relying  on  the 
proficiency. 
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# 

Level 

Level  Description 

4 

Advanced 

Individual  can  perform  the  actions  associated  with  this  proficiency  without  assistance. 

The  individual  has  consistently  provided  practical  and  relevant  ideas  and  perspectives  on 
ways  to  improve  the  proficiency  and  its  application  and  can  coach  others  on  this 
proficiency  by  translating  complex  nuances  related  to  it  into  easy  to  understand  terms. 
Individual  participates  in  senior  level  discussions  regarding  this  proficiency  and  assists  in 
the  development  of  reference  and  resource  materials  in  this  proficiency. 

5 

Expert 

Individual  is  known  as  an  expert  in  this  proficiency  and  provides  guidance  and 
troubleshooting  and  answers  questions  related  to  this  proficiency  and  the  roles  where 
the  proficiency  is  used.  Focus  is  strategic.  Individual  have  demonstrated  consistent 
excellence  in  applying  this  proficiency  across  multiple  projects  and/or  organizations. 
Individual  can  explain  this  proficiency  to  others  in  a  commanding  fashion,  both  inside 
and  outside  their  organization. 

During  some  of  the  Helix  interviews  in  2015-2017,  interviewees  were  asked  to  self-evaluate 
their  level  of  proficiency  based  on  the  Atlas  proficiency  model,  at  the  Area  level.  Generally, 
interviewees  evaluated  themselves  on  a  level  of  1  to  10,  where  1  was  'least  proficient'  and  10 
was  'most  proficient'.  This  was  a  subjective  scale  and  hence  when  someone  placed  themselves 
at  an  8  for  a  proficiency  area,  for  example,  it  was  based  on  their  personal  interpretation  on 
what  it  meant.  These  self-evaluations  -  and  subsequent  discussions  on  why  interviewees 
scored  themselves  in  a  particular  way  -  are  expected  to  provide  insights  in  future  research 
towards  defining  those  objective  scales. 

Interviewees  were  asked  to  evaluate  their  proficiencies  at  two  points  in  time:  (1)  at  the  time  of 
the  interview,  and  (2)  at  the  start  of  their  career.  This  enables  a  proficiency  profile  to  be 
plotted,  as  illustrated  in  Figure  7. 

A  note  for  all  proficiency 
profiles  in  this  document: 

these  profiles  all  follow  the 
standard  methodology  for 
radar  diagrams.  Each  axis 
demonstrates  the  data  for 
that  particular  proficiency 
area.  The  center  represents 
a  value  of  "0"  with  each 
level  outward  indicating  a 
step  up  on  the  proficiency 
level,  (i.e.  the  first  ring  is 
"1/Novice"  and  the  last  ring 
is  "5/Expert". 

Mindset 

Figure  7.  Proficiency  Profile  of  an  Individual 


Now  — -  Start  ot  Career 


Math  /  Science  /  General 
Engineering 


System's  Domain  & 
Operational  Context 


Systems  Engineering 
Discipline 


Report  No.  SERC-2018-TR-101  -B 


22 


January  16,  2018 


The  proficiency  profile  is  not  meant  to  be  exact  since  the  self-evaluations  are  subjective,  and 
individuals  may  have  over-evaluated  or  under-evaluated  themselves.  Also,  'Start  of  Career' 
could  be  as  recent  as  five  years  ago  for  one  individual  or  twenty-five  years  ago  for  another. 
However,  this  exercise  enables  a  discussion  around  the  relative  strengths  in  specific 
proficiencies;  how  proficiency  levels  changed  over  time;  and  what  factors  or  forces  caused  or 
enabled  those  changes. 

The  primary  intent  of  Atlas  is  not  to  just  understand  the  current  state  of  effective  systems 
engineers,  but  to  support  the  development  of  future  systems  engineers  who  will  be  effective. 
From  a  proficiency  perspective,  it  would  mean  setting  target  levels  for  proficiency  areas,  as 
illustrated  in  Figure  8. 

^^“Now  Start  of  Career  . Target  Level 


Math  /  Science  /  General 
Engineering 


Mindset 


System's  Domain  & 
Operational  Context 


Systems  Engineering 
Discipline 


Figure  8.  Proficiency  Profile  with  Target  Levels 


4.1.3  Creating  Retrospective  Proficiency  Profiles 

Many  people  want  to  jump  into  the  Atlas  proficiency  model  by  focusing  on  their  current 
effectiveness.  However,  the  Helix  team  recommends  that  an  individual  actually  start  by  creating 
retrospective  proficiency  assessments.  Why  is  this  important?  This  helps  an  individual  in  a 
number  of  ways.  Unlike  current  assessments,  retrospective  assessments  feel  less  "high  stakes" 
-  less  likely  to  potentially  impact  current  and  future  job  prospects.  Therefore,  people  are  more 
likely  to  rate  themselves  lower  on  retrospective  proficiencies;  i.e.  they  are  less  likely  to  suffer 
from  overestimation  which  plagues  most  self-assessments.  They  also  provide  an  excellent 
opportunity  for  an  individual  to  get  comfortable  with  the  proficiency  model,  with  a  chance  to 
build  consistent  understanding  and  application  of  the  different  proficiency  levels  in  a  no-risk 
way. 

To  build  a  retrospective  proficiency  model,  the  Helix  team  recommends  that  one  pick  a  specific 
point  in  time,  generally  around  a  distinct  milestone  such  as  graduation  with  a  bachelors  or 
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masters  degree,  a  first  systems  engineering  position,  etc.  It  can  be  helpful  to  review  your 
resume  or  CV  to  remember  exactly  what  your  career  path  had  looked  like  to  date.  Then  you  will 
tailor  the  proficiency  model,  build  your  understanding  of  the  rubric,  and  perform  your  self- 
assessment.  If  possible,  getting  external  validation  about  your  assessment  is  very  helpful.  Most 
of  these  steps  may  be  iterative. 

1.  Tailor  the  Model.  For  each  of  the  proficiency  areas,  review  the  list  of  categories.  For 
categories  that  are  broken  into  topics,  identify  the  key  topics  that  were  most  important 
at  this  point  in  your  career.  Note  that  this  may  change  over  time.  For  example,  an 
individual  may  start  in  a  large  defense  company  for  which  physics  and  calculus  are 
critically  important  topics  and  later  work  at  a  medical  device  company  where  biology 
and  chemistry  become  more  heavily  weighted.  In  addition,  certain  proficiencies  may 
have  been  more  critical  than  others  at  this  point  in  time,  which  can  also  be  noted.  Use 
this  approach  to  create  a  tailored  version  of  the  proficiency  model.  In  Figure  6,  this  is 
illustrated  in  the  following  ways:  highlighted  categories  were  seen  as  the  most 
important  in  each  area;  greyed  out  categories  were  seen  as  not  relevant  for  this 
position;  "handwritten"  notes  highlight  the  specifics  for  categories  that  were  most 
important  for  this  point  in  time. 

2.  Build  Your  Understanding  of  the  Rubric.  The  rubric  highlighted  in  Table  2  is  relatively 
simple.  However,  spend  some  time  coming  up  with  examples  to  help  you  internalize 
each  of  these.  The  following  all  proved  to  be  useful  techniques  during  self-assessments 
supported  by  the  Helix  team: 

a.  Internal  Exploration 

i.  Think  about  a  mentor  who  you  respect. 

ii.  Think  about  a  peer  who  you  work  with  frequently. 

iii.  Think  about  someone  at  your  organization  who  is/was  more  junior  than 
yourself. 

How  would  you  rate  these  individuals  in  these  areas?  Why?  What  does  it  mean, 
specifically,  that  one  is  a  "5/Expert"  in  systems  engineering  discipline  or  a 
"2/Novice"  in  technical  leadership?  How  does  this  compare  with  other 
individuals  of  similar  seniority?  The  key  here  is  to  think  of  specifics.  This  will  help 
guide  you  when  you  think  about  your  own  capabilities. 

Atlas  utilizes  a  5-point  scale,  but  this  is  still  qualitative.  Some  individuals  have 
preferred  to  use  a  10-point  scale  or  using  decimals,  to  allow  for  additional 
granularity  (e.g.  "I  am  Expert  in  some  categories  and  Advanced  in  others  for  this 
proficiency  area;  I  want  to  show  that  I  am  between  the  levels,  so  I  will  record  a 
4.5").  This  is  fine  and  particularly  if  you  are  using  the  proficiency  model  only  for 
your  own  internal  understanding,  the  scale  itself  is  less  important  than  using  it 
consistently.  There  are  a  few  items  worth  noting:  using  too  many  decimal  places 
implies  a  precision  that  does  not  really  exist  in  these  types  of  qualitative 
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assessments.  For  example,  in  one  self-assessment  when  we  were  using  a  3-point 
scale,  an  individual  rated  himself  as  a  "2.75".  When  asked  what  this  meant,  it 
was  that  he  "was  not  yet  the  best,  but  was  definitely  a  top  performer".  But  the 
two  decimal  places  implied  that  there  was  a  lot  more  quantitative  rigor  to  the 
assessment  than  existed  in  reality.  The  Helix  team  recommends  the  5-point  scale 
outlined  in  Table  2,  but  if  you  prefer  more  granularity,  we  encourage  you  not  to 
use  more  granularity  than  half-steps  (e.g.  1.5,  2.5,  etc.)  or  to  use  a  10-point 
scale.  And,  if  you  are  performing  your  self-assessment  as  part  of  a  larger  effort 
within  your  organization,  it  is  important  to  utilize  a  consistent  scale;  your 
organization  should  provide  guidance  on  this,  (see  Section  5.3) 

b.  Group/External  Exploration  -  "I  had  said  I  was  a  '4'  in  this  area,  but  if  you  are  a 
'4',  then  I  am  not  more  than  a  '3'.  Did  I  over-rate  myself  or  did  you  under-rate 
yourself?"  This  was  the  common  type  of  discussion  in  Helix  self-assessment 
group  sessions. 

Because  many  of  the  self-assessments  for  the  Helix  project  were  done  in  small 
groups,  it  was  common  as  individuals  shared  their  own  insights  and  ratings  for 
others  to  adjust  their  assessments.  Ideally,  the  rubric  will  create  a  consistent 
expectation  for  ratings.  But  the  truth  is,  that  it  is  still  somewhat  subjective.  The 
conversations  around  differences  in  levels  led  to  conversation  around 
understandings  of  what  the  definitions  for  the  levels  really  mean  in  context.  It  is 
important,  if  you  choose  to  do  group  exercises  for  this  kind  of  work,  that  you 
select  a  group  of  individuals  with  whom  you  have  already  built  trust,  as  open 
communication  is  critical. 

3.  Self-Assess.  Using  the  tailored  proficiency  model  and  the  understanding  you've  built  of 
the  different  proficiency  levels  outlined  in  Table  2,  perform  your  own  self-assessment. 
Figure  6  is  an  example  of  a  completed  self-assessment  using  the  paper-based  tools. 

In  Figure  6,  the  individual  noted  that  this  was  for  when  she  completed  her 
undergraduate  degree  and  began  her  first  job.  In  five  of  the  six  proficiency  areas,  the 
individual  highlighted  what  she  believed  was  the  most  important  category  for  her  at  the 
time.  In  some  areas,  grey  text  indicates  areas  which  she  believed  were  not  relevant  to 
her  position  at  the  time.  It  is  not  surprising  that  with  several  categories  not  relevant  at 
the  time,  she  did  not  highlight  a  category  of  highest  importance  in  the  "Technical 
Leadership"  area. 

The  self-assessments  for  this  point  in  time  are  also  included  in  Figure  9,  and  in  this  case 
reveal  a  few  common  patterns  -  after  graduate  the  highest  proficiency  was  considered 
in  Math/Science/General  Engineering,  with  strong  skills  in  Interpersonal  Skills  and 
Systems  Mindset. 
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Building  and  Orchestrating  a  Diverse  Team 


Balanced  Decision  Making  &  Rational  Risk 
Taking 


Guiding  Diverse  Stakeholders 


Conflict  Resolution  &  Barrier  Breaking 


Business  and  RM  Skills 


Establishing  Technical  Strategies 


Enabling  Broad  Portfolio- Level  Outcomes 


Self-Assessment 


Communications  -  oral -presentation 


Listening  and  Comprehension 


Working  in  a  Team 


Influence,  Persuasion,  and  Negotiation  - 
influence 


Building  a  Social  Network 


Self-Assessment 


Most  Important 


Self  Assessment 

Date  or  Position: 

undergraduate  graduation/ 

workforce  entry 


Interpersonal 


Natural  Science  Foundations  -physi 


Engineering  Fundamentals 


Probability  and  Statistics 


Calculus  and  Analytical  Geometry 


Computing  Fundamentals 


Self-Assessment 


Principal  and  Relevant  Systems  -aircraft 


Familiarity  with  System's  Concept  of 
Operations 


Relevant  Domains  -  defense,  aerospace 


Relevant  Technologies  -  radar,  jet 
propulsion 


Relevant  Disciplines  and  Specialties  - 
electrical,  mechanical,  software, 
aeronautical  engineering; 
th  ervuod  y  na  mics 


System  Characteristics  -  subsystems, 
moderate  complexity 


Self-Assessment 


Big  Picture  Thinking 

Lifecycle  -  system-  definition,  system 
idealization 

Paradoxical  Mindset  -  ~e>ig  picture  §  detail; 
analytic  and  synthetic 

Systems  Engineering  Management  - 
Planning,  risk,  management 

SE  Methods,  Processes,  and  Tools  - 
Modeling  and  simulation; 
organization's  SE  tools  (Poors) 

Adaptability 

Abstraction 

Foresight  and  Vision 

Systems  Engineering  Trends 

-  mose 

Self-Assessment 

3 

Self-Assessment 

2 

Figure  9.  Retrospective  Self-Assessment  Example 

4.  Validate  with  Feedback.  It  may  seem  unusual  that  an  individual  would  rate  themselves 
as  "Advanced"  in  any  area  immediately  after  graduation,  but  in  fact  this  was  quite 
common.  Part  of  the  reason  is  that  individuals  often  do  not  realize  their  own  limitations 
in  their  earlier  careers.  As  the  saying  goes,  "They  don't  know  what  they  don't  know." 
This  is  the  reason  that  finding  some  way  to  get  feedback  or  do  some  baselining  can  be 
so  important.  A  trusted  peer,  mentor,  or  supervisor  can  provide  valuable  feedback  that, 
again,  helps  to  build  internal  consistency  in  how  the  rubric  is  applied. 

Note  that  this  assessment  is  stated  as  if  it  would  be  performed  in  isolation.  In  fact,  systems 
engineers  grow  based  upon  their  career  paths.  Atlas  also  includes  guidance  on  how  to 
characterize  and  assess  one's  career  path  (see  Section  4.2).  In  practice,  the  Helix  team  has  done 
career  profiles  both  before  and  after  proficiency  assessments.  There  was  not  a  clear  "best"  way 
to  do  this.  Usually  after  an  individual  completed  a  career  profile,  they  could  more  readily 
identify  how  they  had  grown  or  changed  in  proficiency  over  time,  but  generally  this  did  not 
change  their  proficiency  assessments.  Please  refer  to  the  Career  Path  Guidebook  for  additional 
insights  on  the  relationships  between  career  path  and  proficiency. 

The  past  profile  is  helpful  for  many  reasons.  Charting  a  few  retrospective  proficiencies  can  be 
very  helpful  in  identifying  areas  of  growth,  stagnation,  or  even  lessening  of  skills  over  time.  This 
gives  a  historical  perspective  that  can  help  someone  more  accurately  gauge  their  current 
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proficiencies  (see  Section  4.1.4)  and  have  a  better  basis  for  planning  future  proficiency  goals 
(see  Section  4.1.5) 


4.1.4  Creating  A  Current  Proficiency  Profile 

The  current  proficiency  is  the  area  that  most  Helix  participants  have  been  most  interested  in 
exploring,  specifically  asking  the  questions,  "How  am  I  doing?"  and  "How  do  I  stack  up  against 
my  peers?"  For  the  latter,  the  Helix  team  is  working  on  building  a  web-based  tools  that  would 
allow  anonymized  data  collection  and  comparison  for  any  individuals  who  use  the  tool  and 
agree  to  be  included.  For  the  former,  the  proficiency  model  provides  a  useful  tool  to  give 
individuals  insight. 

The  process  for  creating  a  current  proficiency  profile  are  the  same  as  creating  a  retrospective 
one:  tailor  the  proficiency  model,  build  your  understanding  of  the  rubric,  perform  your  self- 
assessment,  and  validate  with  feedback. 

1.  Tailor  the  Model.  If  you  started  with  a  retrospective  profile,  you  already  have  at  least 
one  tailored  version  of  the  model.  However,  you  should  still  review  to  determine 
whether  your  tailored  version(s)  is  as  applicable  now  as  it  was  in  the  past  and  update  as 
appropriate.  In  the  example  discussed  earlier,  perhaps  you  worked  in  a  large  aerospace 
and  defense  corporation  and  now  you  work  in  a  company  that  makes  medical  devices.  It 
would  be  expected  that  the  model  would  change;  in  particular  the  topics  chosen  for 
"systems  domain  and  operational  context"  may  be  very  different,  with  medical  and 
physiological  specialties  becoming  more  important  and  technologies  such  radar 
becoming  irrelevant  in  your  new  position. 

2.  Build  Your  Understanding  of  the  Rubric.  As  stated  previously,  this  is  important  for 
internal  consistency  and  to  help  you  review  patterns  in  your  growth  and  change  over 
time.  There  are  no  changes  in  how  this  done  from  the  discussion  above. 

3.  Self-Assess.  Again,  perform  your  self-assessment  based  on  your  current  performance. 
Figure  10  shows  an  example  of  how  the  individual  whose  profile  you  reviewed  in  Figure 
6  might  have  grown  over  her  career. 

When  your  self-assessment  is  completed,  it  is  useful  to  understand  your  own  changes 
over  time  as  well  as  how  this  compares  with  other  systems  engineers.  For  example,  note 
that  in  Figure  10,  the  Math/Science/General  Engineering  proficiency  actually  decreased; 
in  the  retrospective  assessment  it  was  a  "4"  or  "Advanced",  and  in  the  current 
assessment  it  is  a  "3"  or  "Intermediate".  This  is  a  common  pattern,  as  individuals  move 
from  positions  focused  on  roles  like  detailed  design  to  positions  where  roles  such  as 
Systems  Architect  or  System  Integrator  become  more  prevalent.  In  other  words,  there  is 
a  baseline  of  required  Math/Science/General  Engineering  skill  to  be  able  to  work  with 
engineers  and  lead  engineering  work  -  but  when  your  position  emphasizes  other  skills, 
it  is  natural  that  these  may  decline  slightly  as  other  skills  grow. 
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Self-Assessment 


Most  Important 


Self  Assessment 
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Current  assessment 
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Tech  Leadership 
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Sys's  Domain  &  Op 
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Engineering  Fundamentals 


Probability  and  Statistics 


Calculus  and  Analytical  Geometry 


Computing  Fundamentals 


Self-Assessment 


Principal  and  Relevant  Systems  -aircraft 


Familiarity  with  System's  Concept  of 
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Relevant  Domains  -  defense,  aerospace 


Relevant  Technologies  -  radar,  jet 
propulsion 


Relevant  Disciplines  and  Specialties  - 
electrical,  mechanical,  software, 
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Big  Picture  Thinking 

Lifecycle  -  system,  definition,  system. 
'Realization 

Paradoxical  Mindset  -  Big  picture  §  detail; 
analytic  and  synthetic 

Systems  Engineering  Management  - 
Planning,  rlsle  management 

SE  Methods,  Processes,  and  Tools  - 
Modeling  and  simulation; 
organization's  se  tools  (Poors) 

Adaptability 

Abstraction 

Foresight  and  Vision 

Systems  Engineering  Trends 

-Mose 

Self-Assessment 

5 

Self-Assessment 

5 

Figure  10.  Example  Current  Proficiency  Profile 


4.  Validate  with  Feedback.  Getting  some  external  validation  and  feedback  on  current 
proficiency  is  perhaps  more  critical  than  on  retrospective  profiles.  This  helps  you  get  a 
sense  of  where  you  are  today  and  will  help  you  "fill  the  gaps"  in  any  blind  spots  you 
might  have  about  your  performance.  Again,  trusted  peers,  leaders,  or  managers  are  all 
excellent  individuals  to  give  you  feedback  and  help  you  adjust  your  profile  or  mature 
your  rationale  for  your  ratings. 

The  current  profile  is  useful  not  only  from  improving  your  self-awareness  but  also  to  provide  a 
solid  base  on  which  to  plan  your  future  growth. 


4.1.5  Creating  a  Target  Proficiency  Profile 

A  prerequisite  for  creating  a  target  proficiency  is  creating  your  current  proficiency.  Without  this 
basis  on  where  you  are,  it  will  be  very  difficult  to  create  a  realistic  growth  path.  For  example,  if 
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you  are  creating  a  target  for  one  year  away  and  you  identify  that  you  want  to  be  a  "5"  or 
"Expert"  in  Systems  Engineering  Discipline,  but  you  do  not  realize  that  you  are  currently  at  a 
level  "2",  you  may  not  understand  that  you  are  setting  unrealistic  goals  for  yourself. 

The  process  for  creating  a  target  proficiency  profile  is  the  similar  to  creating  a  retrospective  or 
current  one:  1)  tailor  the  proficiency  model,  2)  build  your  understanding  of  the  rubric,  3) 
identify  realistic  targets,  and  4)  validate  with  feedback.  Because  steps  1  and  2  are  the  same, 
please  review  the  information  above. 

The  real  difference  here  is  identifying  what  your  target  should  be,  as  opposed  to  assessing 
where  you  are  or  were.  There  are  a  few  critical  inputs  for  this: 

•  How  far  out  are  you  targeting?  Generally,  the  Helix  team  has  worked  with  individuals  to 
create  target  profiles  from  one  to  five  years  out  from  the  current  time.  Beyond  that,  it  is 
difficult  to  judge  what  may  be  realistic. 

•  What  are  your  interests?  The  first  question  to  ask  yourself  when  creating  a  target 
profile  is,  what  are  you  actually  interested  in?  What  kind  of  work  keeps  you  engaged 
and  what  becomes  drudgery.  This  does  not  mean  that  you  can  create  a  world  where 
every  moment  of  your  professional  life  is  exciting.  But  understanding  where  your 
interests  lie  can  be  useful  in  guiding  your  career.  As  one  senior  systems  engineers  who 
participated  in  Helix  stated,  "I  thought  I  would  enjoy  being  a  systems  engineering 
manager  [an  organizational  manager  responsible  for  systems  engineers].  It  did  not  take 
me  long  to  realize  that  this  was  not  a  good  fit  for  me  and  I  quickly  looked  for  a  new 
position  that  would  put  me  back  into  technical  work." 

This  question  of  whether  to  focus  on  technical  versus  more  supervisor  work,  for 
example,  is  a  common  issue  that  many  junior-  and  mid-level  systems  engineers  in  Helix 
reported  struggling  with.  For  many,  they  had  to  explore  positions  in  both  areas  to 
understand  each  more  clearly  and  make  the  decision.  However,  for  the  purposes  of 
thinking  about  proficiency,  it  is  important  because  it  will  determine  whether  you  will 
focus  on  growing  systems  engineering  proficiencies  or  whether  there  are  other 
proficiencies  around  management  that  will  become  important  to  you. 

•  What  are  your  options?  Some  organizations  provide  guidance  on  career  paths  and 
examples  or  descriptions  of  positions  that  you  may  aspire  to.  Some  organizations  do  not 
offer  these  materials,  but  your  manager,  supervisor,  or  mentor  should  be  able  to  help 
you  understand  these  positions  for  your  organization.  For  example,  is  there  a  position 
such  as  "Chief  Systems  Engineer",  defined  by  Helix  as  the  technical  conscience  and 
primary  technical  authority  for  a  system?  Are  there  Chief  Architects  or  Systems 
Engineering  Leads?  Organizations  will  use  different  titles,  but  understanding  what  the 
more  senior  positions  are  and  what  they  entail  will  provide  critical  information  for  your 
planning. 

It  is  important  to  note  that  for  your  future  planning,  you  do  not  have  to  look  only  within  your 
organization.  Professional  societies  like  INCOSE  (International  Council  on  Systems  Engineering) 
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or  IEEE  Systems  Council  can  be  a  good  resource  to  understand  the  state  of  practice  for  systems 
engineering  and  what  types  of  positions  may  exist. 

When  you  understand  which  types  positions  may  be  of  interest  to  you  in  the  future,  you  can 
start  to  explore  what  proficiencies  are  necessary  to  be  effective  in  those  positions.  For  example, 
you  might  sit  down  with  a  Chief  Systems  Engineer  and  talk  to  them  about  their  daily  activities 
and  what  it  takes  to  do  the  job  well.  Again,  mentors  and  supervisors  can  also  provide  a  wealth 
of  information  on  this.  Some  organizations  may  even  provide  example  profiles  for  individuals  in 
specific  positions.  For  example,  MITRE  has  asked  several  of  its  senior  systems  engineers  to 
create  and  share  their  proficiency  profiles  and  career  paths.  When  individuals  are  planning, 
they  can  use  these  as  a  reference  not  as  an  absolute  "right"  profile,  but  as  guidance  on  areas 
where  they  may  want  to  focus  their  efforts  to  grow. 

As  with  the  retrospective  and  current  profiles,  it  is  important  to  have  some  external  validation 
of  this  career  path.  This  is  an  opportunity  not  only  to  ensure  that  the  growth  path  you  have 
created  is  realistic  on  your  timeline  and  starting  from  your  current  proficiency,  but  if  you  work 
with  your  supervisor  to  validate  your  target,  it  is  also  an  opportunity  to  build  buy-in  with  him  on 
the  ways  in  which  you  can  realistically  growth.  (See  Section  4.2,  below) 


4.2  Career  Path 

The  Helix  team  has  developed  a  Career  Path  Guidebook,  which  provides  the  common  patterns, 
findings,  and  FAQs  around  career  paths  from  the  nearly  200  individuals  with  whom  Helix  has 
these  common  patterns,  please  refer  to  this  companion  document.  The  Helix  team  has  also 
created  templates  that  individuals  can  use  to  assess  their  career  paths  -  paper  based  (Appendix 
B),  Excel-Based  (http://www.sercuarc.org/projects/helix),  and  web-based.  Whatever  tool  you 
use,  it  is  important  to: 

•  Characterize  the  career  path  by  position  (which  is  mapped  to  time), 

•  Provide  the  organizational  context  for  each  position, 

•  Classify  each  position  by  a  number  of  variables. 

Career  paths  are  most  effective  when  they  are  pared  with  proficiency  self-assessments,  which 
can  help  identify  patterns  over  time,  (see  the  Atlas  Career  Path  Guidebook  for  additional 
information) 
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4.2.1  Assessing  Your  Career  Path 


Atlas  outlines  many  variables  that  were  discussed  repeatedly  as  factors  in  how  individuals  grew 
in  their  careers.  These  factors  are  grouped  into  the  three  main  Forces  of  Atlas:  experiences, 
mentoring,  and  education  and  training.  Because  education  is  often  the  easiest  Force  for 
individuals  to  understand  -  they  know  where  they  want  to  school  and  what  they  studied  and 
when  -  the  Guide  starts  with  education  to  help  individuals  get  into  the  mindset  before  tackling 
the  other  Forces. 


4.2. 1.1  Characterizing  Systems  Engineer's  Education 

Education  plays  two  key  roles  in  the  development  of  systems  engineers.  First,  it  provides  the 
foundation  knowledge  to  support  engineering-related  work.  Typically,  this  takes  the  form  of 
undergraduate  education  in  an  engineering  discipline,  technical  field,  or  physical  science. 
Second,  graduate  level  education  is  an  avenue  to  develop  more  advanced  skills,  explore  more 
in-depth  knowledge,  and  help  systems  engineers  grow  as  they  move  through  their  careers. 

To  characterize  education  patterns,  the  following  academic  information  was  extracted  for  each 
systems  engineer  in  the  sample: 

•  Date:  The  date  of  the  completion  of  the  degree  program. 

•  Type  of  Degree:  This  is  the  level  of  education  an  individual  achieved.  The  categories 
used  were:  bachelor's,  master's,  and  doctor  of  philosophy  (PhD).  For  this  analysis,  only 
education  that  resulted  in  a  degree  was  recorded.  Individuals  did  receive  graduate 
certificates  or  took  individual  courses,  but  there  was  not  enough  data  to  draw  any 
meaningful  conclusions.  Also,  if  a  degree  was  in  progress  but  not  completed,  it  was  not 
recorded. 

•  Field  of  Study:  The  primary  discipline  on  which  the  individual's  education  was  focused. 
These  were  initially  recorded  as  reported.  Over  time,  categories  of  related  fields  of 
study  were  created. 


4.2. 1.2  Characterizing  Systems  Engineer's  Experiences 

Experimental  literature  on  experiences  has  primarily  focused  on  two  metrics  for  experience: 
time  (e.g.  Ford  et  al.  1993;  Schmidt  et  al.  1986;  Firth  1979;  Davidz  2006)  and  the  frequency  of 
times  a  specific  task  or  activity  of  interest  was  performed.  Additional  literature  classifies  human 
subjects  based  on  their  experiences  -  which  is  subtly  different  than  classifying  the  experiences 
themselves  -  often  using  a  combination  of  time  and  the  frequency  of  tasks  performed.  This 
approach  may  also  include  considerations  for  specific  roles  played,  Kor  2003,  Kirschenbaum 
1992).  Additional  literature  in  the  field  of  systems  engineering,  such  as  Sheard's  "Twelve 
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Systems  Engineering  Roles"  (1996)  or  the  Graduate  Reference  Curriculum  for  Systems 
Engineering  (GRCSE)  (Pyster  et  al.  2012)  indicate,  though,  that  the  characterization  of 
experiences  is  critically  important  to  understanding  how  experiences  enable  growth. 

The  first  challenge  is  to  determine  a  common  "unit  of  measure"  for  experience.  Though  time  is 
common,  it  is  not  easily  used  in  the  data  available.  For  example,  if  someone  described  a 
position  they  held  over  a  five-year  period,  they  did  not  explain  the  portion  of  time  taken  up  by 
the  activities  they  performed  over  those  five  years.  In  addition,  several  individuals  submitted 
information  on  their  careers  that  included  detailed  descriptions,  but  did  not  include  markers  for 
chronological  time.  Because  of  these  data  limitations,  the  Helix  team  chose  to  use  a  position  as 
the  unit  of  measure  for  experience. 

Based  on  both  the  literature  and  the  Helix  data  itself,  each  position  has  several  characteristics: 

•  Relevance:  A  'relevant'  position  is  one  that  enables  a  systems  engineer  to  develop  the 
proficiencies  critical  to  systems  engineering. 

•  Position:  Every  systems  engineer  who  is  employed  at  an  organization  fills  a  position  that 
is  established  by  the  organization;  that  organization  also  defines  the  roles  and 
responsibilities  to  be  performed.  Helix  considers  position  as  a  'unit  of  measure'  for 
experience,  since  most  of  the  characteristics  of  experience  are  in  the  context  of  the 
position  that  is  held.  A  'systems  engineering'  position  is  one  where  the  individual's 
primary  focus  was  on  systems  engineering  activities. 

•  Date:  includes  a  starting  and  ending  year.  It  reflects  the  amount  of  time  spent  in  a 
position. 

•  Lifecycle  Stage  Generic  systems  engineering  lifecycle  phases  considered  in  Atlas  are 
based  on  the  lifecycle  phases  in  the  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK).  (SEBoK  Authors  2015).  Phases  include:  Concept  Definition,  System 
Definition,  System  Realization,  System  Deployment  and  Use,  Product  and  Service  Life 
Management,  and  Systems  Engineering  Management. 

•  Roles  describes  the  related  systems  engineering  activities  performed  at  the  position 
held.  Helix  team  identified  16  systems  engineering  roles  which  include:  Concept  Creator, 
Requirements  Owner,  System  Architect,  System  Integrator,  System  Analyst,  Detailed 
Designer,  V&V  Engineer,  Support  Engineer,  Systems  Engineering  Champion,  Process 
Engineer,  Customer  Interface,  Technical  Manager,  Information  Manager,  Coordinator, 
Instructor/Teacher. 

•  Number  of  Organizations:  The  number  of  different  organizations  that  an  individual  has 
worked  at,  not  counting  internal  movement  within  an  organization  across  departments 
or  divisions,  reflects  the  variety  of  types  of  experiences  that  one  may  possess.  The  three 
organizational  sectors  identified  are  government,  industry,  and  academia. 
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•  Systems:  There  are  many  aspects  to  the  types  of  systems  on  which  a  systems  engineer 
could  work.  Working  across  these  different  categories  provides  valuable  experience  to 
an  individual  systems  engineer. 

o  Domain:  This  is  the  primary  area  of  application  for  the  systems  being  worked  on. 
However,  there  are  many  domain  categorizations;  some  domains  also  relate  to 
industry  sectors. 

o  Type:  Product  systems,  service  systems,  and  enterprise  systems  are  three  major 
types  of  systems,  depending  on  the  nature  and  composition  of  the  system  of 
interest.  System  of  systems  is  another  paradigm  in  systems  engineering,  and 
could  be  a  combination  of  one  or  more  types  of  systems. 

o  Level:  A  systems  engineer  could  work  on  various  levels  of  a  system: 
component/element,  subsystem,  system,  and  platform  or  system  of  systems. 

The  ways  in  which  positions  were  categorized  were  pulled  from  existing  literature  wherever 
possible.  For  example,  a  systems  engineer  working  in  the  commercial  sector  of  a  company  may 
define  lifecycle  in  different  terms  than  those  used  by  a  US  Department  of  Defense  systems 
engineer.  To  normalize  the  discussion,  the  definition  of  life  cycle  stages  from  the  Guide  to  the 
Systems  Engineering  Body  of  Knowledge  (SEBoK)  was  used;  the  interviewee's  own  words  and 
phrasing  were  compared  with  the  descriptions  of  life  cycle  stages  in  the  SEBoK  and  categorized 
appropriately.  (BKCASE  Editorial  Board,  2017)  Likewise,  the  roles  played  by  the  interviewees 
were  based  on  Sarah  Sheard's  "Twelve  Roles  of  Systems  Engineers"  (Sheard,  1996),  although 
roles  have  been  added  to  reflect  what  was  seen  in  the  data.  Where  existing  literature  was  not 
available,  categories  were  created  that  reflect  the  character  of  the  data. 

By  using  the  data  available  for  each  individual,  the  characteristics  of  each  position  played  and 
the  order  that  they  played  them  can  be  identified.  Then,  the  information  can  be  used  to 
develop  a  preliminary  understanding  of  how  career  paths  shape  proficiency. 


4.2.2  Identifying  Key  Positions 

A  third  aspect  of  career  paths  are  the  key  milestones  for  a  systems  engineer's  career.  The  Helix 
team  focused  on  major  steps  or  changes  in  a  systems  engineer's  positions.  A  position  is 
equivalent  to  the  roles  and  responsibilities  associated  with  an  individual's  title.  Organizations 
will  define  what  roles  and  responsibilities  each  position  contains  and  position  descriptions  may 
not  translate  across  organizations.  The  key  positions  identified  for  systems  engineer  included: 

•  First  systems  engineering  position:  This  was  self-identified  by  participants  as  the  first 
position  in  which  systems  engineering  responsibilities  were  the  primary  focus  of  a 
position,  though  they  may  have  non-systems  engineering  responsibilities  as  well.  This 
was  often  difficult  to  identify,  because  participants  indicated  that  their  roles  often 
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transitioned  gradually  and  it  was  hard  to  identify  when  they  officially  became  systems 
engineers,  especially  because  so  many  never  had  that  specific  title.  The  Helix  team 
recorded  this  information  in  whatever  way  it  was  provided  by  participants.  In  a  few 
organizations,  the  hierarchy  and  structure  for  becoming  a  systems  engineer  was  much 
more  well-defined,  and  for  individuals  in  those  organizations,  the  transition  to  systems 
engineer  was  more  easily  identified. 

•  Chief  systems  engineering  positions.  A  chief  systems  engineer  (CSE)  is  someone  who 
has  formal  responsibility  to  oversee  and  shepherd  the  technical  correctness  of  a  system, 
often  coordinating  with  many  other  systems  engineers  who  have  smaller  scopes  of 
responsibility.  These  milestones  are  any  positions  in  which  an  individual  acted  as  a  CSE, 
regardless  of  their  title  within  their  organization. 

•  Project  manager  positions.  A  project  manager  is  someone  who  has  formal  responsibility 
to  oversee  the  programmatic  aspects  of  a  system,  generally  focused  on  budget  and 
schedule.  Project  management  responsibilities  sometimes  overlap  with  SE 
responsibilities,  particularly  those  around  planning  and  management;  in  some  instances, 
a  CSE  may  also  function  as  a  PM. 


4.2.3  Identifying  Key  Training 

For  some  individuals  in  the  Helix  dataset,  there  were  a  few  key  training  opportunities  that  really 
stood  out  as  helping  them  grow.  These  included  trainings  such  as  week-long  leadership  retreats 
or  two-week  rotations  into  other  parts  of  the  organization.  The  idea  here  is  not  to  catalogue 
every  training  course  you  have  ever  taken,  but  to  highlight  training  that  has  been  particularly 
impactful  and  put  it  on  a  timeline  with  your  positions. 


4.2.4  Identifying  Key  Mentoring 

As  with  training,  mentoring  comes  in  many  different  forms.  For  the  career  path,  it  is  useful  to 
identify  areas  where  mentoring  was  particularly  prevalent  and  can  be  tied  directly  to  growth. 
Examples  in  the  Helix  dataset  included  shadowing  where  a  senior  systems  engineer  sat  down 
and  explained  all  of  the  ins  and  outs  of  a  legacy  system  or  more  senior  systems  engineers 
guiding  individuals  on  how  to  deal  with  a  particular  customer  or  facet  of  systems  engineering. 


4.2.5  Career  Path  Timeline 

Visualizing  the  career  path  can  in  some  ways  be  just  as  helpful  as  the  analysis  described  above. 
It  is  the  opportunity  to  put  all  of  the  disparate  pieces  of  your  career  path  together  and  look  at 
them  more  holistically.  In  working  with  individuals  to  create  their  self-assessments,  the  Helix 
team  heard  things  like,  "Wow.  I  thought  I  had  played  a  lot  of  different  systems  engineering 
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roles,  but  looks  at  this,  I  need  to  diversify  more,"  or  "I  had  thought  I  had  spent  plenty  of  time  in 
requirements,  but  now  that  I  look  at  this,  it  has  only  been  a  small  part  of  my  career." 

This  is  not  to  say  that  there  is  a  "right"  or  "wrong"  career  path  -  but  this  holistic  view  allows 
you  to  identify  gaps  or  overlaps  in  a  clear  way.  It  also  provides  you  the  opportunity  to  more 
intentionally  plan  your  career  path  for  the  future.  For  example,  a  gap  in  a  systems  engineering 
role  may  encourage  you  to  focus  on  a  different  project  or  type  of  work  than  you  otherwise 
might.  And  it  should  be  noted  that  gaps  are  not  "bad";  most  career  paths  did  not  include  all  15 
roles.  But  again,  it  allows  you  to  determine  whether  this  is  acceptable  based  on  your  goals  or 
whether  this  is  something  that  should  be  addressed. 

Figure  8  provides  an  example  of  a  career  path  assessment.  As  you  can  see,  pairing  the  career 
path  with  proficiency  assessments  can  provide  additional  insight. 
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Figure  11.  Example  career  path  of  a  chief  systems  engineer  from  the  Helix  sample. 
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4.3  Personal  Characteristics 


Atlas  includes  seven  personal  characteristics  that  were  consistently  cited  as  important  for 
effective  systems  engineers: 

•  Self-Awareness:  The  ability  to  self-reflect  and  become  aware  of  one's  own  strengths, 
weaknesses,  knowledge,  and  lack  thereof. 

•  Ambition  and  Internal  Motivation:  The  desire  to  reach  high  career  positions,  and  the 
ability  to  draw  motivation  and  energy  from  within  in  order  to  accomplish  those  high 
ambitions. 

•  Inquisitiveness:  Possessing  a  high  level  of  curiosity,  wanting  to  know  more  and  have  a 
'hunger  for  knowledge'. 

•  Lifelong  Learning:  Always  looking  to  learn  and  to  keeping  abreast  with  latest 
developments  in  related  disciplines  and  systems,  irrespective  of  seniority  or  position. 

•  Confidence,  Persistence  and  Focus:  Possessing  the  confidence  to  interact  with 
stakeholders  irrespective  of  their  relative  seniority  or  positions;  the  ability  to  stand  firm 
and  not  give-up;  and  the  ability  to  remain  focused  on  the  success  of  the  overall  system. 

•  Professionalism  and  Respect:  Being  professional  in  the  conduct,  mannerisms,  and 
behaviors;  and  treating  others  with  respect,  recognizing  that  other  experts  may  possess 
more  knowledge  and  experience. 

•  Creativity  Systems  engineers  are  expected  to  have  the  ability  to  use  their  imaginations, 
see  new  possibilities  in  the  ideas  of  others,  find  important  problems,  seek  alternative 
solutions,  and  bring  novel,  useful,  and  valuable  changes  into  being.  Creativity  is  a 
mindset;  the  willingness  to  invent,  seek,  and  use  practical  tools  for  innovation  in  the 
face  of  uncertain,  ambiguous,  and  rapidly  changing  conditions. 

Personal  characteristics  are  attributes  of  individuals  that  are  developed  over  time  and  that  can 
be  applied  broadly  to  all  aspects  of  one's  life.  Much  like  proficiencies,  these  attributes  can  be 
enhanced  through  intention,  attention,  and  practice.  There  are  relationships  between  the 
characteristics  and  proficiencies.  For  example,  the  entire  description  of  creating  proficiency 
profiles  above  requires  that  an  individual  have  some  self-awareness  -  an  ability  to  understand 
one's  own  strengths,  weaknesses,  knowledge,  and  lack  thereof.  The  sections  above  site  many 
reasons  why  creating  accurate  proficiency  profiles  may  be  useful.  If  an  individual  is  not  self- 
aware,  it  will  be  difficult  for  him  to  assess  his  own  proficiencies  accurately.  This  is  part  of  the 
reason  that  there  is  a  "validation"  step  recommended  -  it  is  an  opportunity  for  individuals  to 
improve  their  own  self-awareness. 

While  there  may  be  a  relationship  between  some  of  the  personal  characteristics  as  defined 
above  and  a  variety  of  inventories,  style  tests,  or  personality  measures  you  may  have  used  to 
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gain  self-awareness  in  the  past,  there  is  no  one  type  of  assessment  that  will  help  you 
understand  where  you  stand  on  all  of  the  characteristics.  Be  cautious  when  extrapolating  from 
any  assessment  that  purports  to  be  a  stable  measure  of  "personality"  including  measures  like 
Myers-Briggs  and  the  Big  Five  Personality  Traits  inventories.  While  these  inventories  might 
provide  a  current  baseline  on  an  attribute,  they  are  not  designed  to  describe  your  actual 
behavior  or  how  you  are  capable  of  behaving.  "Openness  to  Experience",  for  example,  in  the 
Big  Five,  is  defined  as  "imagination  and  insight;  those  high  in  this  trait  typically  have  a  broad 
range  of  interests,  are  more  adventurous,  and  creative."  Using  the  Big  Five  assessment  of 
"Openness  to  Experience"  may  give  you  insights  that  correlate  to  the  Atlas  personal 
characteristics  of  creativity  and  lifelong  learning.  It  does  not,  however,  show  that  you  are 
currently  using  those  attributes  well  or  imply  that  you  are  not  capable  of  being  creative  at 
work. 

The  Helix  team  suggests  that  whatever  types  of  assessments  you  may  have  used,  you  can 
reflect  upon  the  outcomes  to  develop  a  sense  of  your  strengths,  weaknesses  and  interests.  To 
learn  more  about  antecedents  and  consequences  of  some  of  these  personal  characteristics  the 
team  recommends  that  you  look  at  recent  books  and  videos  by  the  following  authors: 

•  Erica  Andersen:  Learning,  self-awareness,  curiosity,  vulnerability 

o  Andersen,  E.  (2016).  Learning  to  learn.  Harvard  Business  Review,  March,  pp  98- 
101,  R1603J. 

•  Peter  Coleman  and  Robert  Ferguson:  Skillful  conflict  resolution 

o  Coleman,  P.  T.  &  Ferguson,  R.  (2014).  Making  conflict  work.  New  York,  NY: 
Houghton  Miflin  Harcourt  Publishing  Company. 

•  Angela  Duckworth:  Persistence  and  "Grit" 

o  Duckworth,  A.  (2016).  Grit.  New  York,  NY:  Scribner. 

•  Carol  Dweck:  Growth  Mindset 

o  Dweck,  C.  S.  Ph.d.  (2008).  Mindset.  New  York,  NY:  Ballantine  Books. 

•  Linda  Hill,  Greg  Brandeau,  Emily  Truelove,  Kent  Lineback:  leadership  and  collaborative 
innovation 

o  Hill,  L.  A.,  Brandeau,  G.,  Truelove,  E.,  &  Lineback,  K.  (June  2014).  Collective 
genius.  Harvard  Business  Review,  pp  94-102.  Reprint:  #R1406G. 

o  Hill,  L.A.,  Brandeau,  G.,  Truelove,  E.,  &  Lineback,  K.  (2014).  Collective  Genius. 
Boston,  MA:  Harvard  Business  Review  Press. 

•  Tom  and  David  Kelley:  Design  thinking  and  creative  confidence 

o  Kelley,  T.  and  Kelley,  D.  (2013).  Creative  confidence.  New  York,  NY:  Crown 
Business. 

•  Daniel  Pink:  "Drive"  -  personal  aspects  of  motivation  including  autonomy,  mastery,  and 
purpose 

o  Pink,  D.  (2009).  Drive.  New  York,  NY:  Riverhead  Books. 

•  R.  Keith  Sawyer:  Creativity  and  collaboration 
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o  Sawyer,  R.  K.  (2012).  Explaining  creativity.  2nd  Edition.  New  York,  NY:  Oxford 
University  Press. 

o  Sawyer,  R.  K.  (2017).  Group  genius:  The  creative  power  of  collaboration.  New 
York,  NY:  Basic  Books. 
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5:  Using  Atlas  1.1  for  Organizations 


Atlas  can  be  used  by  any  organization  that  considers  systems  engineering  -  an  interdisciplinary 
approach  governing  the  total  technical  and  managerial  effort  required  to  transform  a  set  of 
customer  needs,  expectations,  and  constraints  into  a  solution  and  to  support  that  solution 
throughout  its  life  -  important  to  its  business  or  mission,  regardless  of  whether  they  use  the 
term  "systems  engineering"  or  not. 

Atlas  1.1  reflects  that  the  analyses  on  organizational  characteristics  are  still  evolving.  The 
organizational  characteristics  (culture,  structure,  value  of  systems  engineering,  definition  of 
systems  engineering,  etc.)  have  shown  to  have  a  critical  impact  on  the  effectiveness  of  systems 
engineers.  Most  of  these  are  addressed  individually,  below.  However,  organizational  culture 
permeates  and  also  has  an  impact  on  each  of  these  factors.  For  that  reason,  organizational 
culture  is  addressed  throughout  this  Section  5,  integrated  into  the  various  topics. 


5.1  Implementation  Spectrum 

The  examples  presented  in  Section  3  illustrated  that  there  are  a  wide  number  of  ways  in  which 
an  organization  can  utilize  Atlas,  ranging  from  a  "greenfield"  approach,  where  an  organization 
is  new  or  new  to  systems  engineering  and  uses  Atlas  to  set  up  a  workforce  development 
approach  for  systems  engineering,  to  organizations  with  a  mature  workforce  development 
approach  which  will  simply  cross-reference  their  existing  processes  and  definitions  against  Atlas 
and  identify  any  possible  adjustments. 

The  sections  below  are  meant  to  help  organizations  utilize  Atlas  across  this  spectrum. 


5.2  Developing  and  Communicating  Clear  Expectations  on  Value 

"When  I  get  a  systems  engineer,  I  don't  know  what  I'm  supposed  to  be  getting." 

-Anonymous  Program  Manager  (Helix  Participant) 

"A  lot  of  our  program  managers  don't  understand  what  systems  engineering  is  or 
what  systems  engineers  are  supposed  to  do." 

-Anonymous  Systems  Engineer  (Helix  Participant) 

The  above  quotes  are  just  two  examples  of  many  in  the  Helix  dataset.  In  fact,  the  team 
gathered  quotes  like  this  from  all  22  participating  organizations  -  although  in  some  this  was 
very  common  and  in  some  this  view  was  an  outlier.  What  do  these  organizations  all  have  in 
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common?  There  is  some  level  of  confusion  about  what  capability  systems  engineering  provides 
and  what  value  a  systems  engineer  provides. 

There  are  six  primary  values  for  systems  engineering  defined  in  Atlas,  shown  in  Table  3.  These 
are  listed  in  the  order  of  frequency  of  mentions  in  the  dataset.  These  reflect  common  values 
that  were  heard  across  the  363  participants  and  all  22  organizations  that  have  participated  in 
Helix  and  the  patterns  were  the  same  in  government  and  industry  and  whether  we  were  talking 
to  systems  engineers,  their  peers,  or  their  leadership. 

In  addition  to  the  primary  values,  there  are  several  sets  of  enabling  values  in  Table  3.  These  are 
activities  systems  engineers  perform  that  provide  value  to  a  project  and,  when  combined, 
deliver  the  primary  value.  They  are  in  some  ways  the  "how"  of  the  primary  value's  "what". 
Notice  that  some  of  the  enabling  values  appear  several  times.  Note  that  Value  2,  "Translation" 
does  not  have  an  enabling  value.  This  is  because  when  the  team  asked  how  systems  engineers 
delivered  this  value,  they  provided  critical  proficiencies,  but  nothing  that  rose  to  enabling  values 
(which  generally  require  a  variety  of  proficiencies  to  deliver). 


Table  3.  Primary  Values  Systems  Engineering  Provide 


# 

Primary  Values 

Enabling  Values 

1 

Keeping  and 
maintaining  the 
system  vision 

•  Getting  the  "true"  requirements  from  the  customer  and  creating 
alignment  between  the  customer  and  the  project  team.  (39%) 

•  Seeing  relationships  between  the  disciplines  and  helping  team 
members  understand  and  respect  those  relationships.  (33%) 

•  Balancing  technical  risks  and  opportunities  with  the  desired  end 
result.  (36%) 

•  Providing  the  big  picture  perspective  for  the  system.  (44%) 

2 

Translation  of 
technical  jargon  into 
business  or 
operational  terms 
and  vice  versa 

3 

Enabling  diverse 
teams  to  successfully 
develop  systems. 

(10%) 

•  Effectively  understanding  and  communicating  the  system  vision 
to  the  team,  and  ensuring  that  the  team  is  aligned  with  this 
vision.  (38%) 

•  Helping  the  team  to  understand  the  big  picture  perspective  and 
where  they  fit  within  the  larger  picture.  (38%) 

•  Identifying  areas  of  concern  for  integration  in  advance.  (13%) 

4 

Managing  emergence 
in  both  the  project 
and  the  system  (7%) 

•  Projecting  into  the  future  (14%),  which  includes  staying  "above 
the  noise"  of  day-to-day  development  issues  and  identifying 
pitfalls. 

•  Technical  problem-solving  balanced  with  the  big  picture 
perspective.  (43%) 
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# 


Primary  Values 


Enabling  Values 


5 

Enabling  good 
technical  decisions  at 
the  system  level  (7%) 

•  The  ability  to  see  the  vision  for  the  system  and  communicate 
that  vision  clearly  is  a  key  enabler  to  helping  teams  make  good 
technical  decisions.  (40%) 

•  The  big  picture  perspective  is  critical  for  understanding  the 
system  holistically  and  enabling  system-level  technical  decisions, 
versus  decisions  made  at  the  component  or  sub-system  level. 
(22%) 

•  A  systems  engineer's  solid  grasp  on  the  customer's  needs  is  also 
a  critical  enabler  to  ensuring  that  decisions  made  will  keep  the 
system  on  the  correct  technical  path.  (22%) 

•  Being  able  to  bring  together  a  diverse  team  of  engineers  and 
subject  matter  experts  is  also  critically  important.  (26%) 

•  A  systems  engineer's  problem  solving  abilities  -  particularly  the 
ability  to  focus  on  root  versus  proximal  cause  -  is  also  a  key 
enabler.  (26%). 

6 

Supporting  the 
business  cases  for 
systems  (7%) 

•  Balancing  traditional  project  management  concerns  of  cost  and 
schedule  with  technical  requirements.  (41%) 

•  Understanding  the  position  of  a  system  within  the  organization 
or  customer's  portfolio  and  communicating  this  to  the  team. 

(59%) 

Not  every  systems  engineer  will  provide  every  value  at  all  times.  Some  values  may  be  more 
critical  for  some  parts  of  an  organization  than  others.  Setting  clear  expectations  for  which 
values  an  organization  wants  systems  engineers  to  provide  is  a  critical  first  step  to  maturing 
the  view  of  systems  engineering  in  an  organization.  An  organization  does  not  have  to  simply 
select  from  the  values  in  Table  3;  they  can  and  should  tailor  their  expected  values  to  match  the 
goals  and  capabilities  desired  of  systems  engineers  in  their  organization.  Once  the  values  are 
identified: 

•  They  need  to  be  clearly  communicated  within  any  systems  engineering  organization,  to 
leadership,  and  to  peer  groups.  Many  systems  engineers  who  participated  in  Helix 
reported  having  to  "fight  for  a  place  at  the  table"  with  other  engineers,  program 
mangers,  etc.  In  fact,  this  was  so  pervasive  that  is  prompted  the  Helix  team  to  add  a 
systems  engineering  role  to  Atlas:  Systems  Engineering  Champion.  The  confusion 
around  the  values  that  systems  engineers  provide  greatly  influences  this.  In  fact,  at 
organizations  where  there  was  a  high  level  of  confusion  about  these  values,  almost 
every  participating  systems  engineer  reported  playing  the  "Champion"  role.  At 
organizations  where  this  was  much  less  common,  fewer  individuals  reported  needing  to 
play  this  role. 

A  second  item  to  note  on  communicating  the  values  is  that  in  a  handful  of  organizations 
in  the  sample,  there  were  value  statements  available  and  leadership  believed  that 
these  were  clearly  communicated.  They  were  surprised  to  learn  how  little  these  values 
were  understood  by  different  engineering  specialties,  program  managers,  etc. 
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•  The  values  should  become  part  of  the  way  systems  engineers  are  assessed  and 
rewarded.  Even  organizations  who  had  clear  value  expectations  for  systems  engineers 
did  not  always  have  assessment  or  rewards  systems  that  aligned  with  them.  When  the 
team  asked,  "How  are  you  assessed?"  almost  all  systems  engineers  described  the 
traditional  and  generic  "annual  review  process"  and  stated  that  none  of  them  were 
assessed  based  on  systems  engineering  specific  factors.  The  few  who  were  described 
these  as  individual  goals  generated  between  themselves  and  their  managers.  But 
overall,  it  was  uncommon  for  value  delivery  to  be  included  in  assessment. 

Likewise,  systems  engineers  (as  with  any  employee)  want  to  be  rewarded  for 
exceptional  work.  Many  individuals  highlighted  organizational  practices  that  not  only  do 
not  reward  systems  engineering  work,  but  systemically  reduce  the  importance  of 
systems  engineering  by  placing  a  higher  value  on  conflicting  actions.  One  of  the  best 
instances  of  this  was  the  "hero  culture"  described  in  several  organizations.  Individuals 
described  being  rewarded  for  "putting  in  long  hours  and  not  sleeping  for  the  last 
several  weeks  of  a  project".  When  the  Helix  team  asked  if  there  were  similar  rewards 
for  the  kind  of  up-front  planning  systems  engineering  provides,  they  explained  that  if  a 
program  goes  well,  it  is  almost  anticlimactic.  Most  explained  there  are  no  rewards  for 
the  types  of  systems  engineering  activities  that  allow  a  program  to  avoid  pitfalls  and 
control  costs. 


5.3  Utilizing  Proficiency  Profiles 

In  Section  4.2  (above),  the  team  explains  how  an  individual  can  develop  a  proficiency  profile. 
This  section  explains  how  organizations  can  utilize  proficiency  profiles  for  their  systems 
engineering  workforce  development  efforts. 


5.3.1  Tailoring  the  Proficiency  Model 

As  with  the  recommendations  for  individuals,  the  Helix  team  recommends  that  organizations 
begin  by  reviewing  and  tailoring  the  proficiency  model.  Some  organizations  will  already  have  a 
competency  model  or  similar  assessment  of  skills  for  systems  engineers.  The  recommendation 
is  not  that  Atlas  replace  these  existing  models  but  that  they  at  least  be  compared  to  Atlas  to 
create  a  gap  assessment.  This  way,  if  an  element  of  the  Atlas  proficiency  model  is  going  to  be 
left  out,  it  can  be  an  intentional  decision  and  not  an  oversight.  Two  notional  examples  of  how 
this  might  look  can  be  found  in  Table  4.  Note  that  in  addition  to  tailoring  the  categories  and 
topics.  Organization  2,  also  added  a  new  category  to  "Math/Science/General  Engineering" 
related  to  Social  Sciences,  specifically  psychology  and  sociology. 
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Table  4.  Tailoring  the  Atlas  Proficiency  Framework 


Area 

Category 

Organization  1: 
Defense  Aerospace 

Organization  2: 
Medical  Devices 

1.  Math /Science 
/  General 
Engineering 

1.1.  Natural  Science  Foundations 

Physics  considered  most 
critical 

Chemistry  and  Biology 
considered  most  critical 
Physiology  added  as  a 
Foundation 

1.2.  Engineering  Fundamentals 

<no  tailoring> 

<no  tailoring> 

1.3.  Probability  and  Statistics 

<no  tailoring> 

<no  tailoring> 

1.4.  Calculus  and  Analytical 
Geometry 

Both  are  considered  critical 

Considered  less  critical  than 
Probability  &  Statistics 

1.5.  Computing  Fundamentals 

Considered  less  critical  than 
the  other  categories 

Considered  critical  for 
integration  with  Electronic 
Health  Records  (EHRs) 

1.6.  Social  Sciences 

Sociology  and  Psychology 

2.  Systems'  Domain 
&  Operational 
Context 

2.1.  Principal  and  Relevant 

Systems 

Air-breathing  jet  engines 
Military  aircraft 

Magnetic  Resonance 

Imaging  (MRI) 

X-Ray 

Computerized  Tomography 
(CT) 

2.2.  Familiarity  with  Principal 
System's  Concept  of 
Operations  (ConOps) 

Expectations  about  the  level 
of  familiarity  may  differ  (e.g. 
understanding  basic  in-flight 
operations) 

Expectations  about  the  level 
of  familiarity  may  differ  (e.g. 
actual  experience  in  a 
clinical  setting  to 
understand  use  cases,  how 
system  fits  within  the 
healthcare  environment, 
where  its  use  may  fit  in  an 
overall  process,  etc.) 

2.3.  Relevant  Domains 

Aerospace 

Healthcare 

2.4.  Relevant  Technologies 

Radar 

Sonar 

Navigation  Systems 

MRI 

X-Ray 

CT 

2.5.  Relevant  Disciplines  and 
Specialties 

Mechanical  Engineering 
Electrical  Engineering 
Aerospace  Engineering 
Software  Engineering 
Thermodynamics 
Aerodynamics 

Ergonomics 

Electrical  Engineering 
Mechanical  Engineering 
Biomedical  Engineering 
Software  Engineering 
Ergonomics 

Radiation  Safety 

2.6.  System  Characteristics 

System  level  design  with 
understanding  of  the  system 
of  systems  in  the 
operational  environment 

Systems  of  systems  level 
design  enabling  integration 
with  other  medical  devices 
and  healthcare  IT  systems 

3.  Systems 
Engineering 

3.1.  Lifecycle 

•  V-lifecycle  approach 
emphasized 

•  Spiral/Incremental 
Development  lifecycle 
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Area 


Category 


Organization  1: 
Defense  Aerospace 


Organization  2: 
Medical  Devices 


Discipline 

•  Organization  not 

involved  in  in-service 
operation  and 
maintenance  (full 
handoff  after  delivery) 

model  emphasized 

•  Organization  heavily 

involved  in  in-service 
operation  and 
maintenance 

3.2.  Systems  Engineering 
Management 

<no  tailoring> 

<no  tailoring> 

3.3.  SE  Methods,  Processes,  and 
Tools 

•  Heavy  emphasis  on 
modeling  and 
simulation 

•  Emphasis  on 
operational  safety 

•  Heavy  emphasis  in 

optimization  for 
patient  safety 

3.4.  Systems  Engineering  Trends 

•  Model  Oriented 

Systems  Engineering 

<no  tailoring> 

4.  Systems  Mindset 

4.1.  Big-Picture  Thinking 

<no  tailoring> 

<no  tailoring> 

4.2.  Paradoxical  Mindset 

•  Balance  of  Methodical 
and  Creative  heavily 
weighted 

•  Paradoxical  mindset 
heavily  weighted 

4.3.  Adaptability 

<no  tailoring> 

<no  tailoring> 

4.4.  Abstraction 

<no  tailoring> 

<no  tailoring> 

4.5.  Foresight  and  Vision 

<no  tailoring> 

<no  tailoring> 

5.  Interpersonal 

Skills 

5.1.  Communication 

<no  tailoring> 

<no  tailoring> 

5.2.  Listening  and 

Comprehension 

<no  tailoring> 

<no  tailoring> 

5.3.  Working  in  a  Team 

<no  tailoring> 

<no  tailoring> 

5.4.  Influence,  Persuasion  and 
Negotiation 

<no  tailoring> 

<no  tailoring> 

5.5.  Building  a  Social  Network 

<no  tailoring> 

<no  tailoring> 

6.  Technical 
Leadership 

6.1.  Building  and  Orchestrating  a 
Diverse  Team 

<no  tailoring> 

<no  tailoring> 

6.2.  Balanced  Decision  Making  & 
Rational  Risk  Taking 

<no  tailoring> 

Risk  is  viewed  negatively  by 
this  highly  safety-conscious 
organization;  this  becomes 
focused  on  decision  making. 
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Area 


Category 


Organization  1: 
Defense  Aerospace 


Organization  2: 
Medical  Devices 


6.3.  Guiding  Diverse  Stakeholders 

<no  tailoring> 

<no  tailoring> 

6.4.  Conflict  Resolution  &  Barrier 
Breaking 

<no  tailoring> 

<no  tailoring> 

6.5.  Business  and  Project 
Management  Skills 

•  Project  management  is 
treated  as  a  distinctly 
separate  discipline 
from  systems 
engineering  in  this 
organization.  There  is 
cultural  pressure  not  to 
include  this  as  a 
"systems  engineering" 
proficiency. 

<no  tailoring> 

6.6.  Establishing  Technical 
Strategies 

•  N/A  (Systems 

engineers  do  not  set 
the  technical  strategy 
for  the  organization) 

•  Only  expected  for 

senior  systems 
engineers 

6.7.  Enabling  Broad  Portfolio- 
Level  Outcomes 

•  N/A  (Systems 

engineers  do  not  set 
the  technical  strategy 
for  the  organization) 

•  Only  expected  for 

senior  systems 
engineers 

At  Rolls-Royce  and  ARDEC-SED,  the  existing  competency  model  was  reviewed  against  Atlas. 
ARDEC-SED,  for  example,  explained  that  their  current  competency  model  covered  all  of  the 
elements  of  Atlas,  though  they  were  organized  differently. 

MITRE  worked  with  the  Helix  team  to  crosswalk  the  MITRE  competency  model.  Figure  12,  and 
Atlas  proficiency  model.  This  included  in-depth  discussions  about  each  of  the  categories  and 
topics  and  led  to  some  updates  of  the  MITRE  competency  model  as  well  as  the  Atlas  model. 
Specifically,  it  was  interactions  with  MITRE  that  led  to  the  reorganization  of  categories  in 
"Systems  Engineering  Discipline"  under  the  "Systems  Engineering  Trends"  topic  and  to  the 
addition  of  the  portfolio-  and  organizational-  level  categories  under  "Technical  Leadership." 

Some  areas  were  straightforward  to  align  between  the  competency  and  proficiency  models.  For 
example,  though  organized  differently,  the  MITRE  competency  model  areas  2.0  and  3.0  align 
nicely  with  the  Helix  area  "Systems  Engineering  Discipline".  5.0,  "Collaboration  and  Individual 
Characteristics"  aligns  well  with  categories  in  "Interpersonal  Skills"  and  "Systems  Mindset"  in 
the  Atlas  proficiency  model  as  well  as  the  personal  enabling  characteristics.  The  Enterprise 
perspectives  of  the  MITRE  model  helped  lead  to  the  updates  in  Atlas  described  above.  In 
addition,  MITRE  has  an  initiative  called  "Systems  Engineering  in  the  Modern  Era"  or  "SEME". 
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Though  not  part  of  the  competency  model,  this  aligned  well  with  the  category  "Systems 
Engineering  Trends"  in  the  "Systems  Engineering  Discipline"  area. 


MITRE  Systems  Engineering  Competency  Model 


1.0  Enterprise  Perspectives 

1.1  Comprehensive  Viewpoints 
1.2  Innovative  Approaches 
r  1.3  Foster  Stakeholder  Relationships 


2.0  Systems  Engineering  Life  Cycle 

2.1  Concept  Definition 
r  2.2  Requirements  Engineering 
2.3  Architecture 
r  2.4  Systems  Design  and  Development 
f  2.5  Systems  Integration 
2.6  Test  and  Evaluation 


2.7  Systems  Implementation, 
O&M,  and  Transition 


MITRE 

Systems 

Engineer 


5.9  Integrity 
5.8  Adaptability 
5.7  Results  Orientation 
5.6  High  Quality  Standards 

5.5  Facilitating,  Managing, 
and  Championing  Change 
5.4  Persuasiveness  and  Influence 
5.3  Communicating  with  Impact 
5.2  Building  a  Successful  Team 
5.1  Building  Trust 

5.0  Collaboration  and 
Individual  Characteristics 


3.0  Systems  Engineering 
Planning  and  Management 

3.1  Transformational  Planning 

3.2  Government  Acquisition  Support 
3.3  Contractor  Evaluation 

3.4  Risk  Management 
3.5  Configuration  Management 
3.6  Integrated  Logistics  Support 
3.7  QA  and  Measurement 

3.8  Continuous  Process  Improvement 


4.9  Collaborating  with  Technical  Specialties 
4.8  Communications/Networking  Engineering 
4.7  Software  and  Information  Engineering 
4.6  Safety  Engineering 

4.5  Reliability,  Maintainability,  and  Availability  (RMA)  i 
4.4  Security  Engineering 
4.3  Modeling  and  Simulation 
4.2  Human  Centered  Engineering 
4.1  Cost/Benefit  Analysis 

4.0  Systems  Engineering 
Technical  Specialties 


Figure  12.  MITRE  Systems  Engineering  Competency  Model  (MITRE  2007,  used  with  permission) 

Whether  you  are  starting  with  an  existing  model  or  whether  you  will  be  starting  with  Atlas,  it  is 
important  to  review  the  entire  model,  looking  at  categories  and  topics,  and  determine  whether 
this  organization  works  within  your  organizational  context  and  whether  there  are  proficiencies 
that  do  not  apply  or  which  are  missing  from  the  model  but  important  for  the  systems 
engineering  work  at  your  organizations.  At  MITRE,  for  their  pilot  program  to  utilize  Atlas  to 
guide  their  Clear  Conversations,  they  developed  a  tailored  proficiency  model  that  reflects  both 
their  competency  model  and  Atlas.  Table  5  illustrates  this. 


Table  5.  MITRE  tailoring  of  Proficiency  Model  versus  Atlas  baseline  (MITRE  information  used  with  permission) 


MITRE  Model  for  Clear  Conversations 

Atlas  Proficiency  Areas 

Math/Science/General  Engineering 

Math/Science/General  Engineering 

•  The  MITRE  model  adds  a  category  for 

•  Modeling/Simulation/Analysis  are 

"Modeling,  Simulation,  and  Analysis" 

included  in  "Systems  Engineering 

Discipline"  in  Atlas 
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MITRE  Model  for  Clear  Conversations 

Atlas  Proficiency  Areas 

Systems  Engineering  Foundation 

•  Uses  "General  Systems  Engineering 
Approaches  and  Models",  which  aligns 
with  "Methods  Processes,  and  Tools"  in 
Atlas 

Systems  Engineering  Discipline 

Systems  Engineering  Mindset 

•  Note  that  "Systems  Thinking"  is  used  - 
which  incorporates  many  of  the 
categories  in  the  Atlas  model 

•  Includes  Evidence-Based  Systems 
Engineering 

Systems  Engineering  Mindset 

Systems  Engineering  in  the  Modern  Era 

•  Applied  Complexity  Science 

•  Model  Based  Engineering 

•  Agile  SE 

•  System  of  Systems  Engineering 

•  Human  Machine  Teaming  Systems 
Engineering 

•  Resilient  Systems  Engineering 

Systems  Engineering  Discipline 

•  Systems  Engineering  Trends  category  is 
closely  related  to  the  SEME  category  in 
the  MITRE  model 

Interpersonal  Skills 

Interpersonal  Skills 

Technical  Leadership 

•  Includes  "Understand  operational 
domain  and  associated 
systems/technology" 

Technical  Leadership  and  Systems  Domain  and 
Operational  Context 

In  addition  to  tailoring  the  model  itself,  an  organization  may  also  wish  to  create  a  weighting  of 
specific  categories  or  areas.  For  example,  in  some  government  organizations  the  focus  is  more 
on  oversight  of  systems  engineering  activities  performed  by  a  contractor.  In  this  environment, 
some  of  the  Interpersonal  Skills  and  Technical  Leadership  proficiencies  may  be  weighted  more 
heavily  than  Math/Science/General  Engineering  due  to  the  nature  of  their  work.  Likewise,  a 
small  company  at  which  systems  engineers  function  as  a  "jack-of-all-trades"  may  decide  that  all 
proficiency  areas  carry  equal  weight. 
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5.3. 1.1  Tailoring  the  Assessment  Rubric 


Just  as  the  proficiency  model  itself  should  be  tailored  to  fit  the  context  of  the  organization,  the 
rubric  for  assessment  should  be  likewise  tailored.  For  example,  in  some  organizations  a  "high, 
medium,  low"  band  of  assessments  may  be  preferred.  In  others,  a  "10-point"  scale  is  more 
comfortable  because  it  allows  more  granularity.  Regardless  of  the  scale  chosen,  the 
organization  should  develop  a  clear  rubric  of  what  it  means  to  be  at  a  specific  level.  This  can  be 
done  generally,  as  in  the  Atlas  rubric  in  Table  2  (above),  or  can  be  created  specifically  for  each 
proficiency  area.  At  MITRE,  they  developed  a  rubric  that  is  specific  to  each  area  of  their 
competency  model.  Table  6  provides  a  few  selected  examples  from  this  rubric.  Note  that 
though  MITRE  also  utilizes  a  five-point  scale,  they  do  not  define  proficiency  at  all  five  levels. 
They  instead  provide  guidance  on  the  ends  of  the  spectrum  and  guidance  for  what  it  means  to 
be  in  the  middle.  This  has  generally  proven  enough  information  for  individuals  to  perform  their 
self-assessments,  with  them  selecting  "2"  or  "4"  if  they  are  between  the  descriptions. 


Table  6.  Examples  from  MITRE  Proficiency  Rubric  (MITRE  2017,  used  with  permission) 


Atlas  Proficiency 

Area  /  Category 

Proficiency  Level  "1" 

Proficiency  Level  "3" 

Proficiency  Level  "5" 

1.  Math  /  Science  / 
General  Engineering 

1.1  Natural  Science 

Foundations 

Minimal  awareness  of  the 
basic  concepts  of  physics, 
chemistry,  and  biology 

Proficient  in  some  of  the 
principles  and  concepts  of 
physics,  chemistry  and 
biology.  Limited  practical 
experience  with  principles 

Expert  in  the  principles  and 
concepts  of  physics, 
chemistry  and  biology 
including  practical 
experience,  and  ability  to 
apply  these  in  the  system's 

context 

1.6  Modeling, 

Simulation,  and 
Analysis 

Minimal  awareness  of 
modeling  and  simulation 
languages  and  application, 
to  include  executable 

models.  Minimal 
awareness  of  data  analytics 
approaches  and 
application. 

Proficient  in  modeling  and 
simulation  languages  and 
application,  to  include 
executable  models. 

Proficient  in  data  analytics 
approaches.  Limited 
practical  experience  in 
their  application. 

Expert  in  modeling  and 
simulation  languages  and 
application,  to  include 
executable  models  ability 
to  readily  apply  these 
where  required.  Expert  in 
data  analytics  approaches 
and  ability  to  readily  apply 
these  where  required 

2.  Systems  Engineering 
Foundation 

Most  Categories  in  this  proficiency  Area  are  divided  into  Topics.  You  may  choose  to 
assess  yourself  at  the  Category  level,  but  it  is  recommended  that  you  assess  yourself  at 

the  Topic  level  (where  available). 
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Proficiency  Level  "1"  Proficiency  Level  "3"  Proficiency  Level  "5" 


Atlas  Proficiency 
Area  /  Category 


2.1  Lifecycle 


3.  Systems  Engineering 
Mindset 

3.1  Systems  Thinking 

(foundational  to 
SEME) 

Note:  the  MITRE  Rubric 
includes  additional 
guidance  on  Systems 
Thinking.  The  Helix 
team  is  presenting  only 
a  portion  of  the 
information  here  for 
brevity. 


Minimal  awareness  of 
lifecycle  models  and 
lifecycle  stages 


WRT  Big-Picture  Thinking: 
Minimal  ability  to  think 
beyond  a  narrow  scope  of 
the  problem  or  immediate 
timeframe  at  hand 


WRT  Paradoxical  Mindset: 
Minimal  ability  to  handle 
seemingly  opposed  views, 
little  regard  of  possible 
tension  or  implications 
across  strategic  and  tactical 
concerns 


WRT  Flexible  Comfort  Zone: 
Comfortable  only  strictly 
within  one's  comfort  zone 
and  area  of  technical 
expertise 

WRT  Multi-Scale 
Abstraction:  Minimal  ability 
to  abstract  or  infer  from 
individual  pieces  of 
information  and  relate  to 
environmental  context 


Proficient  in  the 
understanding  of  lifecycle 
models  and  how  systems 
are  developed  and 
managed  through  them. 
An  understanding  of 
specific  system  lifecycle 
stages  and  inter¬ 
relationships.  Limited 
practical  experience  in 
their  application. 


WRT  Big-Picture  Thinking: 
Able  to  think  in  a  limited 
manner  outside  a  narrow 
scope  and  immediate 
timeframe  with  some 
guidance 

WRT  Paradoxical  Mindset: 
Able  to  understand  one  of 
the  opposed  views 
separately  but  not  both  or 
all,  able  to  understand 
either  strategic  or  tactical 
implications 

WRT  Flexible  Comfort  Zone: 
Able  to  permeate  beyond 
one's  comfort  zone  in  a 
limited  manner,  but 
hesitates  to  explore  the 
unknown 


WRT  Multi-Scale 
Abstraction:  Able  to 
abstract  insights  with  some 
guidance  and  prior 
experience  and  understand 
system  in  larger 
operational  context 


Expert  in  the 

understanding  of  lifecycle 
models  and  how  systems 
are  developed  and 
managed  though  them. 

A  deep 

(demonstrated/applied) 
understanding  of  specific 
system  lifecycle  stages  and 
inter-relationships,  and 
ability  to  carry  out  the 
required  technical  activities 
in  each  stage 


WRT  Big-Picture  Thinking: 
Expert  in  thinking  broadly 
along  various  dimensions 
(e.g.,  regarding  broader 
domain  or  enterprise-level 
considerations,  and  linking 
across  apparent  disparate 
domains  such  as 
incorporating  "soft" 
science  with  "hard" 
science)  understanding 
implications  of  near  term 
and  longterm  timelines. 

WRT  Paradoxical  Mindset: 
Expert  in  the 

understanding  of  opposed 
views  and  perspectives, 
ability  to  successfully 
handle  them  and  strategic 
and  tactical  implications 
separately  and  together, 
and  the  ability  to 
successfully  move  from 
one  perspective  to  another 

WRT  Flexible  Comfort  Zone: 
Willing  and  able  to 
permeate  the  boundaries 
of  one's  comfort  zone  with 
ease,  and  able  to 
comfortably  explore  the 


Most  Categories  in  this  Area  are  divided  into  Topics.  Here,  you  may  choose  to  assess 
yourself  at  the  Category  level  or  at  the  Topic  level. 
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Atlas  Proficiency 
Area  /  Category 


Proficiency  Level  "1" 


Proficiency  Level  "3" 


Proficiency  Level  "5" 


unknown  and  readily  seek 
interdisciplinary  SME 

WRT  Multi-Scale 

Abstraction:  Expert  in 
quickly  and  effectively 
abstracting  (from  highly 
detailed  level  to  highly 
conceptual  level)  new  and 
significant  insights  from 
seemingly  disparate  pieces 
of  information  across 
system  and  environmental 
scales 

4.  Additional  Systems 
Engineering  in  the 
Modern  Era  (SEME) 
Capabilities 

This  Area  is  described  at  the  Category  level.  Therefore,  you  should  assess  yourself  at 
the  Category  level  and  Use  SEME  Vision  Whitepaper  as  background  on  each  Category. 

4.1  Applied  Complexity 
Science 

Minimal  awareness  of 
tools,  techniques,  and 
procedures  from 
mathematical  and  scientific 
disciplines  or  engineering 
problems  of  non-linearity, 
emergence,  and 
unpredictability 

Proficient  in  some  tools, 
techniques,  and 
procedures  from 
mathematical  and  scientific 
disciplines.  Limited  ability 
to  use  to  address 
engineering  problems  of 
non-linearity,  emergence, 
and  unpredictability. 

Expert  in  applying  tools, 
techniques,  and 
procedures  from 
mathematical  and  scientific 
disciplines  to  address 
engineering  problems  of 
non-linearity,  emergence, 
and  unpredictability  and 
applying  these  to  sponsor 
problems 

4.2  Model  Based 
Engineering 

Minimal  awareness  of 
model-based  engineering, 
business  process,  physics 
based,  and  operational 
effects  modeling  & 
simulations. 

Proficient  in  model-based 
engineering,  business 
process,  physics  based,  and 
operational  effects 
modeling  &  simulations. 
Limited  practical 
experience  in  integrating 
them  or  in  their  application 

Expert  in  integrating  and 
applying  model-based 
engineering,  business 
process,  physics  based,  and 
operational  effects 
modeling  &  simulations  to 
support  engineering  and 
management  decisions 
throughout  a  system's 
lifecycle  and  applying 
appropriate  techniques  to 
the  sponsor  problems 

5.  Interpersonal  Skills 

Category  5.1  is  divided  into  Topics.  Here,  you  may  choose  to  assess  yourself  at  the 
Category  level  or  at  the  Topic  level. 
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Atlas  Proficiency 

Area  /  Category 

Proficiency  Level  "1" 

Proficiency  Level  "3" 

Proficiency  Level  "5" 

5.1  Communication 

Minimal  ability  to 
successfully  communicate 
any  information  to  any 
audience  in  any  mode 

Able  to  communicate  well 
in  one  predominant  mode 
with  limited  familiar 

audience 

Expert  in  being  able  to 
successfully  and 
unambiguously 
communicate  to  a  variety 
of  audience  and  a  wide 
range  of  technical  and  non¬ 
technical  content,  in 
various  written  and  oral 

modes. 

5.2.  Listening  & 

Comprehension 

Minimal  ability  to  listen  to 
and  understand  others' 
points  and  perspectives 

Able  to  listen  to  other's 
points,  but  limited  ability 
to  comprehend 

Expert  in  listening  and 
successfully 
comprehending  others' 
points  and  perspectives 

6.  Technical  Leadership 

6.1  Building  & 

Orchestrating  a 
Diverse  Team 

Minimal  ability  to  form  or 
lead  a  team  with  any 

success 

Able  to  build  a  team  with 
guidance  but  has  difficulty 
in  handling  or  delegating  to 
a  diverse  team 

Expert  in  bringing  together 
the  right  team  for  the  task, 
being  able  to  synergistically 
draw  individual  strengths 
of  team  members, 
successfully  leading  the 
team  to  achieve  end  goal 

6.6  Understand 
operational 
domain  and 

associated 

systems/technolo 

gy 

Minimal  understanding  of 
domain  and  the  systems/ 
technology  relevant  to  the 
work  program 

Understands  key  domain 
terminology,  mission/ 
business  threads,  CONOPs, 
systems  and  system 
characteristics,  and 
technologies 

Expert  in  leveraging 
understanding  of  domain 
and  associated  systems/ 
technology  to  anticipate 
future  capability  and 
technology  needs 

6.8  Enable  broader 
portfolio 
outcomes 

Not  aware  of  portfolio 
outcomes  associated  with 
projects  being  supported 

Understands  key  portfolio- 
level  dependencies  on 

MITRE  data-driven 
products  and  activities. 

Consistently  drives  toward 
meeting  not  only 
immediate  project  needs 
but  enabling  portfolio-level 

outcomes 

Once  the  rubric  is  developed,  it  is  important  to  ensure  that  individuals  who  will  be  using  it 
understand  and  internalize  it  so  that  it  applied  consistently.  In  several  organizations,  the  Helix 
team  worked  with  small  groups  to  discuss  their  rationale  for  different  proficiency  levels; 
through  these  conversations,  each  group  developed  a  common  understanding  of  how  this 
could  be  applied.  This  kind  of  approach,  particularly  which  includes  feedback  from  the  exercises 
to  clarify  and  further  refine  the  rubric  is  critical. 

In  addition,  it  is  important  to  ensure  that  any  personnel  who  will  help  guide  individuals  or 
provide  feedback  on  creating  proficiency  profiles  understand  the  rubric  and  the  rational  behind 
the  way  the  rubric  was  generated.  Managers,  leaders,  and  mentors  should  all  know  the  rubric 
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clearly  so  that  they  can  assist  individuals  in  creating  their  proficiency  profiles.  This  is  another 
opportunity  to  build  a  shared  understanding  within  the  organization. 

Because  they  are  subjective  assessments,  the  profiles  can  only  be  compared  qualitatively. 
However,  by  ensuring  a  consistent  rubric  that  is  consistently  applied,  the  value  of  having 
profiles  for  your  systems  engineers  will  be  increased. 


5.3. 1.2  Using  Proficiency  Profiles 

Because  they  are  qualitative,  proficiency  profiles  can  not  be  treated  in  the  same  way  as  results 
of  a  standardized  test  or  personality  assessment  like  Meyers-Briggs  which  is  based  on  data  from 
thousands  of  individuals.  However,  when  used  correctly,  proficiency  profiles  can  be  very  useful. 
In  Section  4.1,  individuals  can  find  instructions  on  how  to  create  a  proficiency  profile.  This 
section  focuses  on  what  organizations  can  do  with  the  results  of  those  profiles. 


5.3.2  Using  Profiles  for  Individual  Development 

One  of  the  ways  that  the  Helix  team  first  envisioned  using  profiles  was  for  individual 
development.  Figure  5  provided  an  example  of  how  past,  present,  and  target  profiles  can  be 
compared.  This  approach  is  useful  for  individuals,  but  can  also  be  very  beneficial  to 
organizations.  In  the  Helix  dataset,  individuals  who  understood  how  they  could  grow  within 
their  organizations  expressed  being  less  likely  to  leave  them. 

In  using  proficiency  profiles  for  developing  individual  systems  engineers,  it  is  important  to  pair 
an  individual  with  someone  they  trust  -  this  could  be  their  manager  or  mentor  or  a  leader 
within  a  team,  but  in  order  to  have  open  conversations,  there  must  be  trust  between  the 
individuals.  The  leader,  mentor,  manager,  etc.  should  first  help  by  validating  the  individual's 
self-assessment.  There  are  times  when  individuals  simply  do  not  yet  understand  their  overall 
abilities,  particularly  in  an  individual  is  new  to  an  organization  or  has  only  seen  one  part  of  an 
organization  and  has  not  experienced  the  full  spectrum  of  proficiency  levels. 

Validating  a  self-assessment  does  not  simply  mean  accepting  it,  but  instead  walking  through  it 
with  the  individual  and  discussing  their  rationale  for  their  assessment.  This  is  an  opportunity  to 
make  adjustments  and  to  provide  rationale  for  those  adjustments  in  turn.  Once  the  individual 
and  the  validator  have  agreed  to  the  current  baseline,  perhaps  with  some  historical  context  via 
retrospective  timelines,  the  profiles  can  now  be  used  for  planning. 

As  with  validating  the  current  profile,  this  is  an  opportunity  for  conversation  and  exploration 
about  the  potential  future  path  of  the  individual.  Some  questions  that  should  be  asked  include: 

•  What  is  the  timeline  for  this  target  profile?  Again,  one  to  five  years  tends  to  be  a 
reasonable  timeframe.  Shorter,  and  the  individual  does  not  have  many  opportunities  to 
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grow,  longer  and  the  opportunities  that  will  be  available  in  five  years  are  so  nebulous,  it 
is  difficult  to  chart  a  way  forward. 

•  Is  the  target  realistic?  It  is  particularly  important  to  ask  this  question  with  respect  to  any 
revisions  that  may  have  been  made  to  the  "current"  profile.  If,  for  example,  an 
individual  believed  he  was  a  "3"  or  "Intermediate"  in  Systems  Mindset  and  wanted  to 
reach  "4"  or  "Advanced  in  two  years,  that  may  be  reasonable.  If,  however,  the  current 
assessment  was  updated  to  reflect  a  current  proficiency  of  "2"  or  "Novice",  this  goal 
may  be  unattainable  in  that  time  frame. 

•  What  are  the  most  critical  areas  for  growth?  In  several  exercises  where  the  Helix  team 
guided  individuals  through  this  exercise  -  typically  targeting  three  years  out  - 
individuals  reported  wanting  to  grow  in  all  areas  by  several  levels.  Realistically,  that  is 
unlikely.  It  may  become  important,  therefore,  to  identify  areas  where  an  individual  can 
focus  their  efforts  as  well  as  areas  that  are  important,  but  perhaps  should  be  tackled 
later. 

•  How  can  the  organization  help  the  individual  meet  her  goal?  This  is  a  critical  step 
because  it  is  about  the  actions  an  organization  can  take  to  help  ensure  the  growth  of  its 
systems  engineers.  There  are  many  ways  to  grow,  but  all  of  the  Forces  highlighted  in 
Atlas  should  be  considered.  Some  useful  questions  include: 

o  What  experience  opportunities  can  be  identified?  In  some  organizations  the 
team  worked  with,  there  was  a  great  deal  of  latitude  allowed  for  movement 
within  an  organization  to  gain  different  types  of  experiences.  In  others,  this  was 
seen  as  "disloyal"  and  despite  the  learning  that  might  be  gained,  was  likely  to 
hamper  an  individual's  career  at  least  for  a  time.  The  culture  of  the  organization 
will  be  an  important  consideration  for  this. 

With  that  in  mind,  it  is  important  to  explore  what  opportunities  the  individual 
may  have  to  gain  new  experiences  that  will  help  them  grow  in  the  targeted  area. 
In  the  Helix  data,  100%  of  the  363  participants  agreed  that  experience  was  the 
number  one  Force  for  growing  systems  engineers,  so  exploring  the  potential 
experience  opportunities  within  the  organization  will  be  a  critical  part  of  helping 
an  individual  plan  how  to  reach  her  target. 

■  Is  there  a  rotational  program  or  short  assignment  that  might  help  an 
individual  grow  in  these  areas?  Many  organizations  have  these  types  of 
programs  and  individuals  who  participated  in  them  reported  that  they 
were  useful  for  their  growth  not  only  during  the  assignment  itself,  but 
also  later,  as  they  reflected  on  those  experiences  in  the  context  of 
another  part  of  the  organization  or  system.  Often,  these  are  "high 
potential"  programs,  which  means  the  organization  may  not  be  able  to 
guarantee  a  specific  individual  a  spot  in  the  program.  However,  they  were 
viewed  by  Helix  participants  as  good  ways  to  rapidly  grow  certain 
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proficiencies,  particularly,  the  System's  Domain  and  Operational  Context 
area,  the  Lifecycle  category  of  the  SE  Discipline  area,  and  the  Big-Picture 
Thinking  category  of  the  Systems  Mindset  area. 

o  Can  mentoring  help  the  individual  to  grow  in  some  of  these  areas?  Mentoring, 
the  second  Force  of  Atlas,  was  the  second-most-cited  method  for  growth  by 
systems  engineers  in  the  Helix  dataset.  There  are  many  different  facets  of 
mentoring  (please  see  Atlas  1.1  for  a  detailed  explanation).  Many  of  the 
individual  systems  engineers  who  completed  target  proficiency  profiles  with  the 
Helix  team  stated  that  in  order  to  grow,  they  needed  to  find  a  mentor  in  a 
particular  area.  As  an  organization,  you  can  help  individuals  find  the  right 
mentors  who  may  help  them  grow  in  specific  areas.  Note  the  caveats  on 
mentoring  noted  in  Atlas  1.1,  such  as  the  criticality  of  matching  individuals  with 
common  interests,  personalities  which  are  amenable  to  guidance  and 
instruction,  etc. 

o  Are  there  specific  training  programs  or  courses  that  might  help  this  individual 
grow?  Every  organization  the  team  worked  with  had  some  sort  of  training 
program.  Some  had  programs  specifically  focused  on  systems  engineering  - 
ranging  from  a  one-hour  lunch-and-learn  to  a  one-  or  two-week  immersive 
course.  The  point  is  that  there  may  already  be  training  courses  that  will  help 
individuals  grow  in  specific  areas  and  it  makes  sense  to  identify  these  as  part  of 
the  target  planning  session. 

Note  that  there  were  several  factors  highlighted  in  Atlas  that  impact  the  efficacy 
of  training  and  one  of  the  more  critical  ones  here  is  that  for  an  individual  to 
maintain  any  gains  in  proficiency  from  a  training  course,  the  learning  needs  to  be 
applied  on  the  job  relatively  quickly.  So  planning  a  course  that  would  help  an 
individual  grow,  but  which  will  actually  be  used  for  some  time  is  unlikely  to  be 
helpful  in  the  long  term. 

o  Is  education  an  appropriate  method  for  growth  in  the  critical  area(s)?  Every 
organization  in  the  Helix  sample  had  some  sort  of  educational  program.  They 
ranged  from  simple  tuition  reimbursement  programs  to  systems  engineering 
cohorts  -  collections  of  individuals  who  were  simultaneously  seeking  a  masters 
degree  in  systems  engineering.  Regardless  of  the  type  of  program,  it  is  worth 
reviewing  whether  academic  coursework  (as  opposed  to  training)  might  be  an 
appropriate  way  of  helping  an  individual  grow  desired  proficiencies. 

In  general,  in  the  Helix  sample  junior  and  mid-level  systems  engineers  were  more 
likely  to  pursue  academic  programs  to  improve  their  systems  engineering 
proficiency.  Most  senior  systems  engineers  stated  that  they  were  "too  senior" 
for  a  master's  program  to  make  a  marked  change  in  their  skillsets.  Also,  it  is 
worth  exploring  whether  a  specific  course  is  needed  or  whether  a  full  academic 
program  makes  sense  -  which  is  a  large  commitment  of  time  for  the  individual 
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and  money  and  support  for  the  organization.  For  example,  if  you  and  your 
systems  engineer  agree  that  they  should  get  more  proficient  at  architecture,  is 
there  a  course  on  architecture  at  a  university  which  may  be  more  suitable  than  a 
full  degree  program? 

The  goal  here  is  to  have  individuals  leave  a  career  planning  session  with  not  only  a  target  of 
where  they  plan  to  grow,  but  a  roadmap  for  how  to  get  there  -  the  name  of  a  potential  mentor, 
signed  up  for  a  training  program,  with  a  potential  rotational  assignment,  etc.  (See  Section  5.4 
for  additional  discussion  on  career  paths.) 


5.3.3  Building  Archetypal  Profiles 

Another  way  that  organizations  can  use  proficiency  profiles  in  growing  their  workforce  is  to 
create  archetypes  or  expected  profiles  for  specific  positions  or  points  in  a  career  path.  These, 
then,  become  draft  target  proficiency  profiles  as  described  above.  They  provide  a  reference  for 
individuals  that  lay  out  the  expectations  of  the  organization  and,  paired  with  their  validated 
current  proficiency  profile,  will  enable  them  to  begin  planning,  realistically,  their  goals  and 
career  paths  in  the  near  term. 

At  ARDEC-SED,  the  Helix  team  worked  with  the  management  team  to  develop  a  set  of 
"expected"  profiles  for  several  positions.  The  Helix  team  led  the  managers  through  a  series  of 
discussions  around  what  the  critical  skills  were  for  each  position  and  how  good  an  individual 
needed  to  be  to  be  effective  in  that  position.  The  term  used  in  these  discussions  as  "minimal 
proficiency  to  be  effective"  -  meaning  that  this  was  the  threshold  managers  believed  an 
individual  needed  to  do  the  job  well.  The  team  then  worked  with  individuals  in  those  positions, 
or  who  had  recently  left  those  positions,  and  helped  them  to  assess  their  current  (or  recent 
past)  proficiencies.  The  team  then  compared  these  proficiency  profiles  with  the  expected 
profile  created  by  the  management  team  and  provided  analysis  on  the  discrepancies  and 
alignments  to  the  management  team.  With  this  data,  the  management  team  was  able  to 
determine  whether  or  not  to  change  their  stated  expectations. 

MITRE  has  taken  a  different  approach  to  this.  For  several  key  positions,  MITRE  asked 
acknowledged  experts  to  create  their  own  proficiency  self-assessments,  which  were  then 
validated  in  discussions  with  the  team  leading  the  effort.  These  "example"  profiles  then  provide 
a  basis  for  individuals  interested  in  growing  into  those  positions. 

The  above  are  two  good  examples  of  how  this  can  be  done  in  practice.  There  are  a  few  points 
that  the  Helix  team  learned  from  working  with  these  organizations  that  are  useful  to  note: 

•  Try  not  to  ask  for  a  superhero.  It  is  a  common  and  very  human  thing  to  answer  the 
question,  "How  good  do  you  want  an  employee  to  be?"  with  the  answer  "the  best". 
However,  by  definition,  it  is  not  possible  for  every  single  individual  to  be  the  best  at 
everything.  In  one  organization  the  Helix  team  worked  with,  when  defining  an  expected 
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profile  for  one  position,  the  team  was  told  that  the  individual  needed  to  be  an  "8"  -  on  a 
10-point  scale,  this  would  equate  to  a  "4/Advanced"  on  the  revised  5-point  scale  -  in 
every  competency  area.  While  it  is  possible  for  a  select  few  people  to  be  "advanced"  or 
"expert"  in  all  areas,  realistically,  it  is  not  possible  for  everyone  to  share  this  profile. 

In  fact,  some  individuals  the  Helix  team  worked  with  found  these  "superhero"  profiles 
to  be  discouraging.  Their  rationale  was  that  if  the  organization  truly  expected  them  to 
be  expert  in  everything,  then  there  was  no  way  they  would  be  able  to  fulfill  those 
expectations.  For  very  junior  systems  engineers,  some  felt  that  it  would  take  10-15  years 
to  get  to  that  level;  as  they  all  wished  to  provide  value  and  be  useful  to  their 
organizations  earlier  than  that.  The  problem  is  not  that  they  were  not  providing  value  - 
in  fact,  in  their  positions  and  the  roles  they  played,  many  were  -  but  that  unrealistic 
expectations  make  them  believe  that  their  contributions  could  not  be  valued  by  the 
organization. 

Does  this  mean  that  an  organization  should  lower  its  standards  and  expectations?  Of 
course  not.  But  it  is  important  to  ensure  that  examples  provided  are  actually  attainable 
and  not  just  by  the  "top  5%"  talent  because,  by  definition,  most  of  the  workforce  will 
not  fall  into  the  5%. 

One  thing  to  keep  in  mind  is  that  systems  engineers  do  not  work  in  isolation.  In  some 
organizations,  discussions  about  expectations  led  to  the  realization  that  the  "minimum" 
was  what  was  needed  from  a  team  of  individuals.  For  example,  there  may  be  a  chief 
systems  architect,  but  a  small  team  of  systems  architects  who  support  that  person. 
Instead  of  expecting  that  all  individuals  have  this  "minimum"  set  of  requirements,  it  is 
possible  that  instead  a  team  can  collectively  meet  these  minimums.  Figure  13  shows  an 
example  of  this: 
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Figure  13.  Example  of  team  profiles  compared  to  an  "expected"  profile. 
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In  Figure  13,  the  expectation  for  proficiency  for  a  systems  architect  is  shown  as  quite 
high  in  all  areas,  which  would  be  difficult  for  any  individual  to  achieve.  But  if  within  that 
organization  systems  architecture  is  actually  created  via  a  team,  then  understanding 
how  the  team  fits  on  the  spectrum  may  be  helpful.  In  this  example,  the  team  profile  fills 
the  expectations  more  fully  than  any  of  the  individuals'  profiles.  Not  that  even  with  this 
team  perspective,  it  appears  that  there  is  a  gap  in  Technical  Leadership  and  Systems 
Engineering  Discipline.  This  could  represent  potential  areas  of  growth  within  the  team  - 
perhaps  with  specific  individuals  targeting  specific  areas  of  growth  -  or  could  represent 
an  example  of  where  the  expectations  are  not  quite  aligned  with  the  proficiencies  that 
are  truly  required.  In  either  case,  having  the  data  to  compare  these  is  a  critical  step  in 
helping  the  organization  align  required  knowledge,  skills,  abilities,  behaviors,  and 
cognitions  with  existing  abilities.* 

*  Collect  data  to  determine  how  aligned  the  archetypes  are  with  current  organizational 
realities.  Again,  this  does  not  mean  that  an  organization  can  not  set  a  high  standard  for 
a  position  but  that  the  expectations  need  to  have  some  alignment  with  realities. 

For  example,  imagine  the  following  scenario:  an  organization  creates  an  example  profile 
for  their  "systems  analyst"  position,  in  which  the  expectation  was  that  a  minimum 
proficiency  of  "4"  or  "Advanced"  was  required  in  all  proficiency  areas.  All  of  the 
individuals  who  currently  in  that  position  create  current  proficiency  profiles,  which  are 
validated  with  their  supervisors.  Their  self-assessments  show  that  they  range  from  an 
average  of  2.5  to  4  in  all  proficiency  areas,  as  illustrated  in  Figure  14. 


Figure  14.  Example  result  of  data  collection  against  an  archetypal  profile. 


Note:  It  is  also  possible  that  there  is  some  synergy  between  the  individuals  that  would  raise  the 
“collective”  profile  of  the  team.  This  is  an  area  the  Helix  team  hopes  to  investigate  further  in  future. 
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If  used  improperly,  the  results  in  Figure  14  might  indicate  that  all  individuals  currently  in 
the  system  analyst  position  fall  below  the  "minimum"  standard  and  could  not  possibly 
be  effective.  However,  what  is  more  likely  is  that  management  expectations  and  reality 
do  not  align.  In  fact,  the  Helix  team  saw  this  phenomenon  at  several  organizations.  With 
this  data,  the  management  team  can  now  re-evaluate  their  example  profile. 

Does  this  mean  that  an  organization  can  not  set  a  higher  standard  than  currently 
available  in  their  workforce?  Not  at  all.  However,  indicating  to  employees  that  they  do 
not  meet  expectations  and  providing  no  further  input  would  be  disastrous.  Instead,  in 
such  an  instance,  the  management  team  should: 

o  Re-assess  the  example  profile  and  make  adjustments  as  appropriate.  This  could 
include  creating  multiple  profiles.  For  example  in  the  example  above,  perhaps 
there  is  a  "minimum"  profile,  which  is  not  a  "4"  or  "Advanced"  in  all  areas,  and 
an  "expert"  profile,  which  shows  the  highest  proficiency  profiles  expected  in  an 
area. 

o  Clearly  communicate  with  the  individuals  in  the  position  what  the  expectations 
are  when  they  create  their  proficiency  profiles,  such  as  how  the  data  will  be 
used. 

o  If  the  "expected"  profile  remains  the  same,  it  would  be  critical  to  help  individuals 
who  do  not  meet  that  profile  to  create  a  plan  for  growth  so  that  they  can  begin 
to  close  the  gap  between  their  current  and  the  "expected"  profile. 

•  Do  not  overuse  archetypal  profiles  or  apply  them  too  rigidly.  This  is  related  to  the 
point  on  expectations  above.  Having  clear  goals  and  targets  can  be  very  useful  if  they 
are  employed  in  the  right  way.  Giving  an  individual  an  "expected"  profile  with  no 
additional  information,  however,  can  lead  to  discouragement.  As  discussed  above,  this 
can  be  counter  productive.  It  is  important  to  be  clear  about  what  the  examples  or 
archetypes  really  mean.  For  example,  is  this  a  true  minimum  for  a  position?  If  so,  and 
especially  if  the  profile  falls  into  the  "superhero"  pitfall,  some  people  may  never  plan  on 
trying  to  attain  that  position. 

No  matter  what  techniques  ore  approaches  an  organization  chooses  to  use,  a  common  pattern 
seen  in  the  Helix  team's  work  with  multiple  organizations  is  that  clear  communication  is  critical 
if  these  example  or  archetypal  profiles  are  going  to  be  used  successfully  in  an  organization. 


5.4  Utilizing  Systems  Engineering  Roles 

Atlas  provides  a  list  of  15  systems  engineering  "role"  -  specific  sets  of  related  systems 
engineering  activities.  These  roles  were  founded  on  Sheard's  "Twelve  Systems  Engineering 
Roles"  (1996)  and  modified,  expanded,  and  reorganized  based  on  the  Helix  dataset.  The  roles 
are  detailed  in  Atlas  1.1,  but  Table  7  briefly  defines  each  role.  For  additional  discussion  on  the 
roles,  how  they  were  developed,  and  how  they  are  organized,  see  Atlas  1.1.  For  an 
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understanding  of  how  the  roles  impact  career  paths,  please  see  the  Atlas  Career  Path 
Guidebook. 


Table  7.  Fifteen  Systems  Engineering  Roles 


# 

Role  Name 

Role  Description 

1 

Concept  Creator 

Individual  who  holistically  explores  the  problem  or  opportunity  space  and 
develops  the  overarching  vision  for  a  system(s)  that  can  address  this  space. 

2 

Requirements 

Owner 

Individual  who  is  responsible  for  translating  customer  requirements  to  system 
or  sub-system  requirements;  or  for  developing  the  functional  architecture. 

3 

System  Architect 

Individual  who  owns  or  is  responsible  for  the  architecture  of  the  system. 

4 

System  Integrator 

Individual  who  provides  a  holistic  perspective  of  the  system;  this  may  be  the 
'technical  conscience'  or  'seeker  of  issues  that  fall  in  the  cracks'  -  particularly, 
someone  who  is  concerned  with  interfaces. 

5 

System  Analyst 

Individual  who  provides  modeling  or  analysis  support  to  system  development 
activities,  and  helps  to  ensure  that  the  system  as  designed  meets  he 
specification. 

6 

Detailed  Designer 

Individual  who  provides  technical  designs  that  match  the  system  architecture; 
an  individual  contributor  in  any  engineering  discipline  who  provides  part  of 
the  design  for  the  overall  system.  This  is  an  addition  based  on  the  Helix  data. 
While  systems  engineers  do  not  always  get  involved  with  detailed  design,  in 
smaller  organizations  or  on  smaller  projects  it  is  more  common. 

7 

V&V  Engineer 

Individual  who  plans,  conducts,  or  oversees  verification  and  validation 
activities  such  as  testing,  demonstration,  and  simulation. 

8 

Support  Engineer 

Individual  who  performs  the  'back  end'  of  the  systems  lifecycle,  who  may 
operate  the  system,  provide  support  during  operation,  provide  guidance  on 
maintenance,  or  help  with  disposal. 

9 

Systems 

Engineering 

Champion 

Individual  who  promotes  the  value  of  systems  engineering  to  individuals 
outside  of  the  SE  community  -  to  project  managers,  other  engineers,  or 
management.  This  may  happen  at  the  strategic  level  or  could  involve  looking 
for  areas  where  systems  activities  can  provide  a  direct  or  immediate  benefit 
on  existing  projects. 

10 

Process  Engineer 

Individual  who  defines  and  maintains  the  systems  engineering  processes  as  a 
whole  and  who  also  likely  has  direct  ties  into  the  business.  This  individual 
provides  critical  guidance  on  how  systems  engineering  should  be  conducted 
within  an  organization  context. 

11 

Customer 

Interface 

Individual  who  coordinates  with  the  customer,  particularly  for  ensuring  that 
the  customer  understands  critical  technical  detail  and  that  a  customer's 
desires  are,  in  turn,  communicated  to  the  technical  team. 

12 

Technical  Manager 

Individual  who  controls  cost,  schedule,  and  resources  for  the  technical  aspects 
of  a  system;  often  someone  who  works  in  coordination  with  an  overall  project 
or  program  manager. 
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13 

Information 

Manager 

Individual  who  is  responsible  for  the  flow  of  information  during  system 
development  activities.  This  includes  the  systems  management  activities  of 
configuration  management,  data  management,  or  metrics. 

14 

Coordinator 

Individual  who  brings  together  and  brings  to  agreement  a  broad  set  of 
individuals  or  groups  who  help  to  resolve  systems  related  issues.  This  is  a 
critical  aspect  of  the  management  of  teams. 

15 

Instructor/Teacher 

Individual  who  provides  or  oversees  critical  instruction  on  the  systems 
engineering  discipline,  practices,  processes,  etc.  While  any  discipline  could 
conceivably  have  an  instructor  role,  this  denotes  a  focus  on  systems  and  is  a 
critical  component  in  the  development  of  an  effective  systems  engineering 
workforce. 

Note:  In  some  organizations,  the  term  "role"  is  used  to  define  what  is  in  Atlas  referred  to  as  a 
position:  a  specific  job  or  title.  This  is  not  a  problem,  but  particularly  if  you  are  using  the  roles 
within  an  organization  that  uses  this  terminology,  it  will  be  important  to  clarify.  For  example,  in 
one  organization  that  uses  "role"  to  mean  "job  title",  they  call  the  Atlas  roles,  "activities". 


5.4.1  Using  Roles  to  Clarify  the  Value  of  Systems  Engineers 

Section  4.1  provides  insight  on  clarifying  the  value  that  systems  engineers  and  systems 
engineering  are  expected  to  provide  within  an  organization.  Another  way  in  which 
organizations  can  help  to  clarify  its  expectations  of  value  is  to  clearly  define  the  systems 
engineers  roles  within  the  organization.  Start  with  the  roles  identified  in  Table  5,  organizations 
should  review  the  roles  and  update  them  to  reflect  the  organizational  context.  For  example,  in 
most  government  systems  engineering  groups  that  participated  in  Helix,  the  role  of  "concept 
creator"  was  uncommon.  Individuals  explained  that  given  the  DoD  acquisition  process,  the 
higher  level  concepts  were  usually  created  before  the  systems  engineers  were  engaged.  This  is 
not  necessarily  "wrong",  but  provides  an  opportunity  for  reflection  about  whether  or  not 
systems  engineers  should  be  engaged  at  this  stage. 

Likewise,  there  may  be  additional  duties  that  a  systems  engineer  performs  in  a  specific 
organization.  For  example,  in  some  small  organizations,  it  is  common  for  systems  engineers  to 
also  perform  program  management  duties.  In  the  Helix  dataset,  this  is  reflected  as  "role  that 
systems  engineers  often  perform",  but  not  a  "systems  engineering  role".  However,  within  your 
organization,  this  may  be  an  expected  part  of  value  that  systems  engineers  provide.  In  some 
organizations,  systems  engineers  work  closely  with  marketing  department  to  ensure  that  what 
is  communicated  to  the  public  accurately  reflects  the  capabilities  of  the  company's  offerings. 
This,  too,  could  be  added  as  a  systems  engineering  role. 

Once  an  organization  has  created  a  set  of  standard  roles  for  systems  engineers,  this  becomes  a 
tool  for  helping  to  clarify  the  values  that  systems  engineers  provide.  If  an  organization  states, 
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for  example,  that  "Systems  Integrator"  is  a  systems  engineering  role  that  is  critical  in  the 
organization,  that  helps  to  reinforce  that  systems  engineers  provide  value  to  projects  by 
ensuring  that  issues  that  could  arise  as  components  and  subsystems  are  brought  together  are 
identified  and  dealt  with  earlier,  helping  to  improve  the  overall  performance  of  the  program. 
This  aligns  nicely  with  the  Enabling  Value,  "Systems  engineers  provide  the  big  picture 
perspective,  which  is  critical  for  understanding  the  system  holistically  and  enabling  system-level 
technical  decisions,  versus  decisions  made  at  the  component  or  sub-system  level."  Whatever 
values  are  selected,  they  provide  clear  examples  of  how  systems  engineers  are  expected  to 
contribute  to  products  and  programs. 


5.4.2  Using  Roles  to  Clarify  the  Positions  of  Systems  Engineers 

As  seen  in  the  Helix  dataset,  it  was  common  that  a  systems  engineer  play  more  than  one  role  in 
any  given  position.  (See  the  Career  Path  Guidebook  for  additional  details.)  Several  organizations 
shared  with  the  Helix  team  -  as  did  their  systems  engineers,  program  mangers,  and  classic 
engineers  -  that  one  of  the  frustrations  commonly  seen  was  the  use  (or  misuse)  of  systems 
engineering  titles.  Program  managers  at  several  organizations,  for  example,  stated,  "When  I  get 
a  systems  engineer  on  my  project,  I  don't  know  what  I'm  getting.  Am  I  getting  someone  who 
will  help  the  team  work  better  together,  understand  the  requirements,  and  help  me  work  with 
the  customer?  Or  am  I  getting  someone  who  just  graduated?  There  is  no  way  to  know." 

Using  the  systems  engineering  roles  to  clarify  positions  may  help  to  alleviate  some  of  these 
issues.  For  example,  the  Helix  team  examined  the  first  "chief  systems  engineer"  role  played  by 
all  the  chief  systems  engineers  in  the  sample.  The  results  are  shown  in  Figure  15. 
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Figure  15.  Roles  played  during  initial  chief  systems  engineering  positions. 


Using  the  types  of  patterns  outlined  in  the  Career  Path  Guidebook  and  the  internal  patterns 
within  your  systems  engineering  organization,  it  is  possible  to  build  common  patterns  that  link 
to  specific  positions.  For  example,  using  the  information  in  Figure  15,  an  organization  may 
define  a  chief  systems  engineering  (CSE)  position  using  the  roles  illustrated  in  Figure  16. 


Position:  Chief  Systems  Engineer 
(CSE) 


Key  Roles 


Description:  Individual  granted 
formal  responsibility  to  oversee 
and  shepherd  the  technical 
planning ,  decision  making ,  and 
execution  for  a  program.  The  CSE 
will  maintain  a  consistent  vision 
for  a  system ,  often  coordinating 
with  many  other  engineers  who 
have  smaller  scopes  of 
responsibility  as  well  as  with  the 
Program  Manager. 


All  CSEs  are  expected  to 
perform  in  the  following 
roles: 

•  Technical  Manager 

•  Coordinator 

•  Customer  Interface 

•  System  Integrator 

•  System  Architect 


Figure  16.  Example  description  of  CSE  position  using  roles. 
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In  Figure  16,  a  chief  systems  engineer  will  guide  the  program,  manage  technical  decisions,  help 
improve  interfaces  not  only  within  the  system  but  among  the  teams  working  on  the  system, 
and  support  or  develop  the  architecture  for  the  system.  The  CSE  would  not  be  expected  to 
perform  roles  not  described;  for  Figure  16,  CSEs  they  would  not  likely  be  V&V  Engineers  or 
Support  Engineers.  (Though  they  would  work  with  these  individuals  in  their  role  as 
coordinator).  While  CSE  may  be  a  well-understood  position,  using  a  standard  and  consistent  set 
of  roles  clearly  sets  expectations  for  the  skills  provided  by  individuals  in  each  position.  One 
could  imagine  that  if  all  systems  engineering  positions  are  defined  in  this  way,  it  would  create  a 
clearer  and  more  consistent  picture  of  the  activities  systems  engineers  are  expected  to 
perform.  Paired  with  expectations  around  proficiency,  the  clarity  around  a  position  increases, 
as  illustrated  in  Figure  17.  Systems  engineers  would  have  clearer  expectations  of  what  it  means 
to  perform  in  a  position.  Program  and  project  managers  would  better  know  what  to  ask  for 
when  developing  their  teams. 


Position:  Chief  Systems 
Engineer  (CSE) 


Key  Roles 


Description:  Individual 
granted  formal  responsibility 
to  oversee  and  shepherd  the 
technical  planning,  decision 
making,  and  execution  for  a 
program.  The  CSE  will 
maintain  a  consistent  vision 
for  a  system,  often 
coordinating  with  many  other 
engineers  who  have  smaller 
scopes  of  responsibility  as  well 
as  with  the  Program  Manager. 


All  CSEs  are  expected  to 
perform  in  the  following 
roles: 

•  Technical  Manager 

•  Coordinator 

•  Customer  Interface 

•  System  Integrator 

•  System  Architect 


Proficiency 


Minimum  —Average 


Figure  17.  Position  description  showing  roles  and  proficiency. 


This  type  of  activity  also  provides  an  opportunity  to  identify  any  gaps.  For  example,  if  an 
organization  creates  its  tailored  list  of  systems  engineering  roles,  then  maps  these  roles  across 
all  systems  engineering  positions,  the  organization  can  then  review  whether  all  of  the  roles  are 
clearly  covered.  If  a  role  is  important  but  not  part  of  a  position,  this  is  a  chance  for  the 
organization  to  add  this  explicitly  -  or  determine  whether  the  role  is  actually  critical.  Likewise, 
duplicates  where  the  same  role  appears  across  multiple  positions  indicate  an  area  where  it 
would  be  helpful  to  clarify  the  scope  of  the  role  within  positions.  All  of  these  activities  give 
opportunities  to  minimize  duplicate  effort  while  streamlining  and  improving  integration  of 
common  activities.  And,  again,  provide  an  excellent  tool  to  help  non-systems  engineers 
understand  who  systems  engineers  are  and  the  activities  they  can  perform  on  a  project. 
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5.5  Utilizing  Career  Paths  -  Understanding  the  Forces  that  Grow  Systems  Engineers 

The  career  path  of  Atlas  is  the  characterization  of  the  Forces  over  time:  Experiences, 
Mentoring,  and  Education  and  Training.  The  Career  Path  Guidebook  provides  data  on  common 
patterns  of  career  paths  seen  in  the  Helix  sample,  which  may  be  very  useful  to  organizations 
that  are  trying  to  create  or  update  their  career  paths  for  systems  engineers.  The  focus  here  is 
on  how  career  paths  may  be  useful  for  an  organization.  Note  that  while  the  term  "career  path" 
is  used  throughout  this  section,  this  does  not  mean  that  there  is  only  one  way  to  grow  as  a 
systems  engineer  or  than  an  organization  will  have  only  one  approach  for  developing  its 
systems  engineers.  More  likely,  an  organization  will  have  a  set  of  "career  paths"  or  a  framework 
of  career  guidance.  However,  for  simplicity  of  language,  the  Helix  team  uses  the  term  "career 
path". 

One  of  the  organizations  that  worked  with  the  Helix  team  has  a  very  clear  career  path  for 
systems  engineering  -  expected  stages,  a  standard  set  of  diverse  experiences,  areas  of  potential 
specialization,  and  even  a  process  by  which  individuals  in  the  organization  become  "official" 
systems  engineers  (and  a  process  to  get  there).  This  is  a  very  mature  approach  for  a 
organization  which  views  systems  engineering  as  one  of  its  core  capabilities.  It  is  not  the  only 
approach  that  works,  but  does  have  some  advantages.  First,  by  defining  a  clear  career  path 
analogous  to  those  for  electrical,  mechanical,  or  software  engineers,  it  puts  systems 
engineering  as  a  discipline  on  equal  footing  with  these  classic  engineering  disciplines.  It  also 
helps  individuals  understand  where  they  are  in  the  career  path  and  where  they  can  expect  to 
grow.  In  this  organization,  systems  engineers  were  able  to  envision  a  clear  future  for 
themselves  at  this  organization. 

Though  more  than  one  organization  in  the  Helix  dataset  provided  career  guidance,  for  most 
organizations  in  the  Helix  sample,  this  type  of  clear  and  distinct  career  path  did  not  exist.  When 
the  Helix  team  asked  about  career  paths,  the  results  were  varied,  ranging  from  an 
"organizational  understanding  about  what  works"  that  was  not  documented  to  statements  that 
the  guidance  differed  greatly  depending  on  to  whom  you  spoke,  to  outright  laughter.  Important 
for  any  organization  that  hopes  to  grow  and  mature  its  workforce,  however,  is  that  fact  that  in 
all  of  these  organizations,  systems  engineers  expressed  a  strong  interest  in  having  clearer 
guidance  on  their  careers  and  clear  paths  or  methods  to  grow  and  many  were  frustrated  by  the 
this. 

Developing  a  clear  career  path  for  systems  engineers  gives  the  organization  a  few  advantages: 

•  It  further  supports  the  organization's  view  of  the  value  systems  engineers  provide.  By 

creating  a  clear  and  distinct  career  path  for  systems  engineers,  it  puts  them  on  equal 
footing  with  many  other  disciplines  that  have  established  career  paths.  It  signals  to  the 
systems  engineers  themselves  and  to  their  peers  that  it  is  a  critical  discipline  for  the 
organization.  It  also  is  a  clear  indicator  that  the  systems  engineers  themselves  are 
valuable  enough  to  the  organization  that  this  sort  of  time  and  effort  should  be  applied. 
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•  It  reduces  dependence  on  institutional  memory.  Many  of  the  systems  engineers  that 
participated  in  Helix  said  that  they  got  career  guidance  from  their  manager  or  mentor  or 
perhaps  the  "one  person  everyone  knows  that  always  can  help  you  figure  out  what 
should  be  next".  When  the  team  asked  whether  this  guidance  or  the  context  of  the 
guidance  was  actually  of  use,  participants  explained  that  when  the  guidance  came  from 
someone  who  had  seen  many  systems  engineers  over  the  years  and  "just  had  a  sense 
for  what  worked".  These  individuals  form  a  valuable  resource  for  the  organization.  The 
problem  arises  when  these  individual  leave  the  organization  and  this  intuitional  memory 
is  lost.  By  collecting  the  input  from  these  individuals  and  using  it  to  construct  a  career 
path,  the  organization  protects  that  knowledge  and  experience. 

•  It  may  help  with  retention  of  systems  engineers.  As  stated  above,  many  systems 
engineers  who  participated  in  Helix  cited  frustration  with  the  lack  of  clear  guidance  they 
were  able  to  access  for  their  personal  growth.  Perhaps  even  more  telling,  many  systems 
engineering  managers  in  the  sample  stated  that  they  could  identify  more  than  one 
instance  of  a  systems  engineer  leaving  the  organization  because  they  could  not 
understand  how  they  might  grow  and  develop.  By  creating  clear  career  paths,  it  helps 
enthusiastic  systems  engineers  visualize  how  they  might  improve.  Paired  with  clear  roles 
and  example  positions,  a  systems  engineer  can  understand  the  variety  of  positions  he 
may  be  able  to  play  and  will  have  a  basis  for  more  intentionally  driving  his  career  path. 


5.6  Critical  Factors  in  Organizational  Initiatives 

Organizational  initiatives  are  the  methods  organizations  develop  in  an  attempt  to  grow  their 
systems  engineering  workforce,  generally  through  applying  one  of  the  three  Forces 
(experiences,  mentoring,  or  education  and  training).  Common  examples  include  training 
courses,  rotational  programs,  apprenticeships,  mentor  programs,  and  graduate  cohorts. 

When  individuals  discussed  successes  and  failures  with  organizational  initiatives,  there  were 
four  factors  that  stood  out  as  critical  to  the  success  of  any  initiative: 

•  Establishing  the  right  initiative:  Like  in  any  good  systems  engineering  development, 
identifying  the  requirements  and  addressing  them  appropriately  while  establishing  the 
initiative  is  a  necessary  first  step. 

•  Spreading  the  word:  Any  organizational  initiatives  will  be  ineffective  when  an  intended 
beneficiary  is  unaware  that  such  an  initiative  exists  within  the  organization. 
Organizations  must  take  an  effort  to  let  its  employees  know  about  their  eligibility  and 
existence  of  any  organizational  initiatives,  and  enable  them  to  benefit  from  them. 

•  Periodical  evaluation  of  the  initiative:  Due  to  the  dynamic  nature  of  the  organizational 
environment,  it  is  important  to  critically  evaluate  any  initiative  periodically  to  identify 
modifications  that  need  to  be  made  to  the  initiative. 

•  Commitment  from  leadership:  Even  if  many  relevant  and  effective  initiatives  were 
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available,  commitment  from  the  organizational  and  immediate  leadership  is  essential 
for  an  employee  to  benefit  from  an  initiative. 

These  principles  are  highlighted  throughout  the  sections  above,  but  are  worth  highlighting 
separately  so  that  organizations  can  keep  them  in  mind  when  deciding  whether  to  develop  new 
initiatives. 
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6:  Conclusions:  Bringing  It  All  Together 


Atlas  is  intended  to  provide  systems  engineers  and  organizations  that  employ  systems 
engineers  with  information  on  what  makes  systems  engineers  effective.  This  Implementation 
Guide  is  intended  to  help  take  that  theory  and  put  it  into  practice. 

Individuals  can  use  the  information  to  understand  and  assess  their  own  knowledge,  skills,  and 
abilities;  understand  and  analyze  their  own  career  paths,  and  link  the  two  to  develop  plans  and 
paths  for  growth. 

Organizations  will  be  able  to: 

•  Clear  and  consistent  definitions  for  systems  engineering  and  the  value  that  systems 
engineer  provide; 

•  Clear  and  consistent  expectations  on  the  roles  systems  engineers  play  within  the 
organization; 

•  Clear  and  consistent  expectations  on  the  knowledge,  skills,  abilities,  behaviors,  and 
cognitions  of  systems  engineers; 

•  Career  path  recommendations  and  supporting  initiatives  that  enable  the  growth  and 
development  of  the  systems  engineering  workforce. 

If  all  of  these  are  brought  together,  an  organization  may  need  to  be  able  to  provide  guidance 
such  as  illustrated  in  Figure  18.  This  example  shows  a  potential  "career  path"  for  an 
organization  over  time  -  in  this  case  a  series  of  positions  expected  to  enable  a  person  to  grow. 
These  positions  include  the  highest-level  systems  engineering  positions  in  the  organization. 
Each  position  provides  clear  guidance  on  the  expectations  in  terms  of  both  the  systems 
engineering  roles  to  be  played  and  proficiencies  associated  with  the  position.  In  this  case,  both 
the  "anticipated  minimum"  proficiencies  (blue  line)  and  the  current  average  proficiencies  of 
individuals  in  this  position  (red  line)  are  included.  Finally,  Figure  18  provides  example  career 
paths  from  individuals  who  currently  serve  in  these  positions.  All  of  this  information  can  be 
utilized  by  individuals  within  the  organization  to  guide  their  own  careers  and  by  managers  and 
leaders  to  help  grow  the  workforce. 

Figure  18  is  notional  and  the  specifics  illustrated  are  far  less  important  than  the  idea  that  an 
organization  can  provide  clear,  consistent  guidance  based  on  rigorous  assessments  and  data 
collection  that  will  enable  them  to  grow  their  workforce. 
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Figure  18.  An  example  career  path,  with  positions,  roles,  and  proficiencies. 

By  using  Atlas,  the  Helix  team  believes  that  organizations  can  better  provide  their  systems 
engineers  with  the  information  and  tools  needed  to  grow  and  develop  into  an  effective 
workforce. 
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Appendix  A:  Paper-Based  Tools  for  Assessing  Proficiency 


Proficiency  defines  the  knowledge,  skills,  abilities,  behaviors,  patterns  of  thinking,  and  abilities 
that  are  critical  to  the  effectiveness  of  systems  engineers.  The  Atlas  proficiency  model  consists 
of  six  difference  proficiency  areas: 

•  Math/Science/General  Engineering:  Foundational  concepts  from  mathematics,  physical 
sciences,  and  general  engineering; 

•  System's  Domain  &  Operational  Context:  Relevant  domains,  disciplines,  and 
technologies  for  a  given  system  and  its  operation; 

•  Systems  Engineering  Discipline:  Foundation  of  systems  science  and  systems  engineering 
knowledge; 

•  Systems  Engineering  Mindset:  Skills,  behaviors,  and  cognition  associated  with  being  a 
systems  engineer; 

•  Interpersonal  Skills:  Skills  and  behaviors  associated  with  the  ability  to  work  effectively  in 
a  team  environment  and  to  coordinate  across  the  problem  domain  and  solution 
domain;  and 

•  Technical  Leadership:  Skills  and  behaviors  associated  with  the  ability  to  guide  a  diverse 
team  of  experts  toward  a  specific  technical  goal. 

Each  of  these  areas  contains  several  categories,  or  groupings  of  related  knowledge,  skills, 
abilities,  behaviors,  or  cognitions,  as  illustrated  in  Table  1. 

Self-Assessment 

In  order  to  perform  a  self-assessment,  individuals  are  asked  to  review  the  definitions  of  the 
proficiency  areas  above  and  the  categories  in  Table  1.  Additional  detail  can  be  found  in  the  full 
report  on  Atlas  1.0,  SERC-2016-TR-118,  found  at  the  Helix  webpage 

(http://www.sercuarc.org/projects/helix/).  Then  use  the  template  to  generate  a  "0  to  10"  initial 
assessment  of  your  current  proficiency  in  each  Area,  with  "0"  meaning  you  have  no  skill  in  the 
area  and  10  meaning  your  skills  are  the  top  within  your  experiences.  Consider  the  following 
guidelines: 

•  For  each  Proficiency  Area,  think  about  proficiency  across  all  categories,  not  just  one.  For 
example,  if  you  are  a  "10"  in  a  single  category,  but  a  "5"  in  all  others,  you  would  not  be  a 
"10"  for  the  entire  Area. 

•  For  each  Area,  think  about  what  is  most  critical  for  your  current  position.  This  may  not 
change  your  assessment,  but  may  mean  that  a  lower  number  not  an  issue. 

•  Consider  your  past  experiences  in  the  Area,  any  training  or  education  that  might  be 
relevant,  and  where  you  might  have  received  guidance  from  a  mentor  or  leader.  These 
things  together  will  have  shaped  your  proficiency,  and  thinking  about  them  may  help 
you  to  assess  yourself  more  realistically. 

•  You  know  your  strengths  and  areas  for  growth  -  be  honest  in  your  responses. 

A  proficiency  rubric  for  further  guidance  can  be  found  on  page  78. 

Once  you  have  completed  your  initial  assessment  for  your  current  proficiency,  you  can  choose 
to  retroactively  assess  what  your  proficiency  was  at  different  points  in  your  career.  For 
example,  when  you  completed  your  undergraduate  education  or  joined  your  current 
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organization.  This  may  help  you  to  better  reflect  on  changes  over  time.  If  you  do  this,  revisit 
your  current  proficiency  assessment  afterwards  and  determine  whether  any  adjustments  are 
required. 

As  discussed  in  the  Implementation  Guide,  you  should  first  review  and  tailor  the  rubric  as 
appropriate  for  your  position. 


Atlas  Self-Assessment  Rubric 

The  following  is  the  self-assessment  rubric  provided  by  Atlas.  As  with  the  proficiency  model 
itself,  you  should  review  and  tailor  this  as  appropriate. 


# 

Level 

Level  Description 

1 

Fundamental 

Awareness 

Individual  has  common  knowledge  or  an  understanding  of  basic  techniques  and 
concepts.  Focus  is  on  learning  rather  than  doing. 

2 

Novice 

Individual  has  the  level  of  experience  gained  in  a  classroom  or  as  a  trainee  on-the-job. 
Individual  can  discuss  terminology,  concepts,  principles,  and  issues  related  to  this 
proficiency,  and  use  the  full  range  of  reference  and  resource  materials  in  this 
proficiency.  Individual  routinely  need  help  performing  tasks  that  rely  on  this  proficiency. 

3 

Intermediate 

Individual  can  successfully  complete  tasks  relying  on  this  proficiency.  Help  from  an 
expert  may  be  required  from  time  to  time,  but  the  task  is  usually  performed 
independently.  The  individual  has  applied  this  proficiency  to  situations  occasionally 
while  needing  minimal  guidance  to  perform  it  successfully.  Individual  understands  and 
can  discuss  the  application  and  implications  of  changes  in  tasks  relying  on  the 
proficiency. 

4 

Advanced 

Individual  can  perform  the  actions  associated  with  this  proficiency  without  assistance. 

The  individual  has  consistently  provided  practical  and  relevant  ideas  and  perspectives  on 
ways  to  improve  the  proficiency  and  its  application  and  can  coach  others  on  this 
proficiency  by  translating  complex  nuances  related  to  it  into  easy  to  understand  terms. 
Individual  participates  in  senior  level  discussions  regarding  this  proficiency  and  assists  in 
the  development  of  reference  and  resource  materials  in  this  proficiency. 

5 

Expert 

Individual  is  known  as  an  expert  in  this  proficiency  and  provides  guidance  and 
troubleshooting  and  answers  questions  related  to  this  proficiency  and  the  roles  where 
the  proficiency  is  used.  Focus  is  strategic.  Individual  have  demonstrated  consistent 
excellence  in  applying  this  proficiency  across  multiple  projects  and/or  organizations. 
Individual  can  explain  this  proficiency  to  others  in  a  commanding  fashion,  both  inside 
and  outside  their  organization. 

Atlas  Self-Assessment  Tool  (Paper  Based) 

The  following  page  provides  the  paper  based  self-assessment  tool  provided  by  Atlas. 


Report  No.  SERC-2018-TR-101-B 


75 


January  16,  2018 


Building  and  Orchestrating  a  Diverse  Team 


Date  or  Position 


Natural  Science  Foundations 


Balanced  Decision  Making  &  Rational  Risk 
Taking 

Guiding  Diverse  Stakeholders 
Conflict  Resolution  &  Barrier  Breaking 
Business  and  PM  Skills 
Establishing  Technical  Strategies 
Enabling  Broad  Portfolio- Level  Outcomes 
Self-Assessment 

Communications 

Listening  and  Comprehension 
Working  in  a  Team 

Influence,  Persuasion,  and  Negotiation 
Building  a  Social  Network 

Self-Assessment 
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Appendix  B:  Paper-Based  Tools  for  Assessing  Career  Path 


An  individual's  career  path  is  the  precise  combination  of  experiences,  mentoring,  education, 
and  training  that  an  individual  goes,  particularly  their  characteristics,  timing,  and  order.  In  order 
to  complete  a  career  assessment,  an  individual  should  work  through  the  steps  outlined  here 
while  filling  out  the  career  path  template. 

Experiences 

The  Helix  team  chose  to  use  a  position  as  the  unit  of  measure  for  experiences;  a  position  is 
established  by  the  organization  and  defines  the  roles  and  responsibilities  to  be  performed. 

Based  on  both  the  literature  and  the  Helix  data  itself,  each  position  has  several  characteristics: 

•  Relevance:  A  'relevant'  position  is  one  that  enables  a  systems  engineer  to  develop  the 
proficiencies  critical  to  systems  engineering.  Determine  a  starting  point  for  relevant 
experiences;  this  will  become  the  first  position  (PI)  of  the  career  path.  Fill  in  the  title 
and  the  year(s)  for  the  position(s). 

•  Organizations:  Fill  out  the  name  of  the  organization  for  each  position.  This  will  help  to 
show  any  transition  or  variation  between  organizations. 

•  Roles:  A  role  is  a  collection  of  related  systems  engineering  activities.  Roles  were 
identified  based  on  the  activities  consistently  performed  by  systems  engineers.  There 
are  16  roles  identified  in  Atlas,  as  described  in  Table  1,  below.  For  each  position,  review 
your  activities  and  responsibilities  and  write  down  all  roles  played  during  that  position. 

•  Lifecycle  Phases:  Generic  systems  engineering  lifecycle  phases  considered  in  Atlas  are 
based  on  the  lifecycle  phases  in  the  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK),  as  explained  on  page  5.  (BKCASE  Authors  2016)  For  each  position, 
fill  in  the  area(s)  of  the  lifecycle  you  worked  on. 

•  Key  Milestones.  Note  any  key  changes  in  types  of  positions  under  key  milestones.  For 
example,  first  systems  engineering  role,  first  chief  systems  engineer  role,  first 
supervisory  position,  etc.  would  all  be  indicators  of  change  or  growth  over  career. 

Education  and  Training 

Note  any  educational  milestones  or  key  training  milestones  with  the  position/timeline  in  which 
they  occurred.  Education  milestones  may  include  the  completion  of  a  degree  or  participation  in 
a  course  that  was  particularly  relevant  or  impactful  for  your  career.  Key  training  is  training  that 
was  particularly  impactful  or  useful  for  your  career.  You  do  not  need  to  include  training  that  did 
not  have  an  impact. 

Other 

Your  organization  may  ask  you  to  add  other  information,  such  as  participation  in  professional 
societies,  publications,  etc.  to  your  career  path. 
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Role  Name 


Role  Description 


Roles  Focused  on  the  Systems  Being  Devleoped 


Concept  Creator 

Individual  who  holistically  explores  the  problem  or  opportunity  space  and 
develops  the  overarching  vision  for  a  system(s)  that  can  address  this  space.  A 
major  gap  pointed  out  to  the  Helix  team  -  particularly  when  working  to 
implement  the  findings  of  Helix  -  has  been  that  of  the  development  of  an 
overarching  system  vision.  This  is  a  critical  first  step  in  the  systems  lifecycle,  and 
several  organizations  stated  that  they  believed  it  needed  to  be  separately  called 
out.  In  addition,  when  looking  to  the  future  of  what  systems  engineers  need  to 
do  (e.g.,  INCOSE  Vision  2025  (2015)),  the  focus  on  early  engagement  and  setting 
the  vision  was  deemed  critical. 

Requirements  Owner 

Individual  who  is  responsible  for  translating  customer  requirements  to  system  or 
sub-system  requirements.  This  is  updated  from  Atlas  1.0.  Sheard  (1996)  also 
included  the  activities  around  functional  architecture  in  this  role.  However,  in 
working  with  the  community,  this  has  caused  some  confusion  as  to  the 
differences  between  this  role  and  that  of  "System  Architect".  The  Helix  team 
believes  that  grouping  all  architecture  activities  together  will  improve  clarity  on 
the  roles. 

System  Architect 

Individual  who  owns  or  is  responsible  for  the  architectures  of  the  system;  this 
including  functional  and  physical  architectures.  This  is  updated  from  Atlas  1.0. 
This  is  an  update  of  Sheard's  "System  Designer"  role  (1996).  There  was  concern 
both  at  community  events  and  during  later  interviews  that  nowhere  in  the 
presented  framework  did  the  critical  role  of  systems  engineers  in  architecture 
come  out  clearly.  Some  also  argued  that  "Design"  gave  the  impression  that  this 
role  focuses  specifically  on  the  details  of  systems  design  over  architecture. 

System  Integrator 

Individual  who  provides  a  holistic  perspective  of  the  system;  this  may  be  the 
'technical  conscience'  or  'seeker  of  issues  that  fall  in  the  cracks'  -  particularly, 
someone  who  is  concerned  with  interfaces.  Likewise,  there  was  concern  over 
the  word  "Glue",  which  many  expressed  was  not  clearly  descriptive  enough. 

System  Analyst 

Individual  who  provides  modeling  or  analysis  support  to  system  development 
activities,  and  helps  to  ensure  that  the  system  as  designed  meets  he 
specification.  This  is  unchanged  from  Sheard's  roles  (1996). 

Detailed  Designer 

Individual  who  provides  technical  designs  that  match  the  system  architecture; 
an  individual  contributor  in  any  engineering  discipline  who  provides  part  of  the 
design  for  the  overall  system.  This  is  an  addition  based  on  the  Helix  data.  While 
systems  engineers  do  not  always  get  involved  with  detailed  design,  in  smaller 
organizations  or  on  smaller  projects  it  is  more  common.  Likewise,  systems 
engineers  who  had  played  this  role  explained  that  it  was  critical  in  developing 
their  own  technical  and  domain  expertise  as  well  as  in  understanding  the  design 
approaches  of  classic  engineers. 

V&V  Engineer 

Individual  who  plans,  conducts,  or  oversees  verification  and  validation  activities 
such  as  testing,  demonstration,  and  simulation.  This  is  unchanged  from  Sheard's 
roles  (1996). 
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Role  Name 


Role  Description 


Support  Engineer 

Individual  who  performs  the  'back  end'  of  the  systems  lifecycle,  who  may 
operate  the  system,  provide  support  during  operation,  provide  guidance  on 
maintenance,  or  help  with  disposal.  This  was  previously  titled  "Logistics  and 
Operations  Engineer"  in  Sheard  (1996).  However,  in  interviews  and  at 
community  events,  the  Helix  team  received  feedback  that  using  this  title  gave 
the  impression  that  this  role  was  limited  and  did  not  encompass  the  full 
spectrum  of  systems  engineers'  activities  at  system  deployment  or  post¬ 
deployment.  Likewise,  in  several  organizations,  "logistics"  and  "operations" 
were  seen  as  separate  disciplines  from  systems  engineering,  which  caused  some 
contention  in  discussions.  The  renaming  of  this  category  is  intended  to  address 
these  issues. 

Roles  Focused  on  Process  and  Organization 

Systems  Engineering 
Champion 

Individual  who  promotes  the  value  of  systems  engineering  to  individuals  outside 
of  the  SE  community  -  to  project  managers,  other  engineers,  or  management. 
This  may  happen  at  the  strategic  level  or  could  involve  looking  for  areas  where 
systems  activities  can  provide  a  direct  or  immediate  benefit  on  existing  projects. 
Sheard  recommended  that  a  role  such  as  this,  labeled  in  her  work  as  "Systems 
Engineering  Evangelist",  be  added  in  (2000). 

Process  Engineer 

Individual  who  defines  and  maintains  the  systems  engineering  processes  as  a 
whole  and  who  also  likely  has  direct  ties  into  the  business.  This  individual 
provides  critical  guidance  on  how  systems  engineering  should  be  conducted 
within  an  organization  context.  This  is  unchanged  from  Sheard's  roles  (1996). 

Roles  Focused  on  the  Teams  That  Build  Systems 

Customer  Interface 

Individual  who  coordinates  with  the  customer,  particularly  for  ensuring  that  the 
customer  understands  critical  technical  detail  and  that  a  customer's  desires  are, 
in  turn,  communicated  to  the  technical  team.  This  is  unchanged  from  Sheard's 
roles  (1996). 

Technical  Manager 

Individual  who  controls  cost,  schedule,  and  resources  for  the  technical  aspects 
of  a  system;  often  someone  who  works  in  coordination  with  an  overall  project 
or  program  manager.  This  is  unchanged  from  Sheard's  roles  (1996). 

Information  Manager 

Individual  who  is  responsible  for  the  flow  of  information  during  system 
development  activities.  This  includes  the  systems  management  activities  of 
configuration  management,  data  management,  or  metrics.  This  is  unchanged 
from  Sheard's  roles  (1996). 

Coordinator 

Individual  who  brings  together  and  brings  to  agreement  a  broad  set  of 
individuals  or  groups  who  help  to  resolve  systems  related  issues.  This  is  a  critical 
aspect  of  the  management  of  teams.  This  is  unchanged  from  Sheard's  roles 
(1996). 

Instructor/Teacher 

Individual  who  provides  or  oversees  critical  instruction  on  the  systems 
engineering  discipline,  practices,  processes,  etc.  This  can  include  the 
development  or  delivery  of  training  curriculum  as  well  as  academic  instruction 
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Role  Name 


Role  Description 


of  formal  university  courses  related  to  systems  engineering.  While  any  discipline 
could  conceivably  have  an  instructor  role,  this  denotes  a  focus  on  systems  and  is 
a  critical  component  in  the  development  of  an  effective  systems  engineering 
workforce.  This  is  an  addition  to  the  Sheard  roles  (1996  and  2000). 


Systems  Engineering  Lifecycle 

•  Concept  Definition  -  A  set  of  core  technical  activities  of  SE  in  which  the  problem  space 
and  the  needs  of  the  stakeholders  are  closely  examined.  This  consists  of  analysis  of  the 
problem  space,  business  or  mission  analysis,  and  the  definition  of  stakeholder  needs  for 
required  services  within  it. 

•  System  Definition  -  A  set  of  core  technical  activities  of  SE,  including  the  activities  that 
are  completed  primarily  in  the  front-end  portion  of  the  system  design.  This  consists  of 
the  definition  of  system  requirements,  the  design  of  one  or  more  logical  and  physical 
architectures,  and  analysis  and  selection  between  possible  solution  options. 

•  System  Realization  -  The  activities  required  to  build  a  system,  integrate  disparate 
system  elements,  and  ensure  that  a  system  both  meets  the  needs  of  stakeholders  and 
aligns  with  the  requirements  identified  in  the  system  definition  stage.  This  includes 
integration,  verification,  and  validation  (IV&V). 

•  System  Deployment  and  Use  -  A  set  of  core  technical  activities  of  SE  to  ensure  that  the 
developed  system  is  operationally  acceptable  and  that  the  responsibility  for  the 
effective,  efficient,  and  safe  operations  of  the  system  is  transferred  to  the  owner. 
Considerations  for  deployment  and  use  must  be  included  throughout  the  system  life 
cycle.  Activities  within  this  stage  include  deployment,  operation,  maintenance,  and 
logistics. 

•  Product  and  Service  Life  Management  -  Deals  with  the  overall  life  cycle  planning  and 
support  of  a  system.  The  life  of  a  product  or  service  spans  a  considerably  longer  period 
of  time  than  the  time  required  to  design  and  develop  the  system.  This  stage  includes 
service  life  extension,  updates,  upgrades,  and  modernization,  and  disposal  and 
retirement.  The  organizations  in  the  current  sample  are  primarily  concentrated  on  new 
development,  so  this  is  a  very  under-represented  aspect  of  the  life  cycle. 

•  In  addition  to  these  life  cycle  phases,  the  SEBoK  includes  orthogonal  activities  of  systems 
engineers,  Systems  Engineering  Management,  defined  as  managing  the  resources  and 
assets  allocated  to  perform  SE  activities.  Activities  include  planning,  assessment  and 
control,  risk  management,  measurement,  decision  management,  configuration 
management,  information  management,  and  quality  management.  These  activities  can 
occur  at  any  point  in  the  systems  engineering  lifecycle. 
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Concept  Definition 
System  Definition 
System  Realization 
System  Deployment  and  Use 
Product  and  Service  Life  Management 
Systems  Engineering  Management 


Role(s) 

Performed 


Domain(s) 

System 

Characteristics 

Position 

Organization(s) 

Dates 


Milestones 
(Key  positions, 
education,  or 
training) 
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